lbryio / reflector.go

MIT License

14 stars 13 forks source link

Investigate/suppress errors in #reflector-logs #25

Closed tzarebczan closed 5 years ago

tzarebczan commented 5 years ago

reflector-logs is full of errors like below. If we know they aren't causing any issues (I know we thought they might be at one point), we should suppress them.

net.OpError write tcp4 172.31.89.3:5567->86.161.0.74:39276: write: connection reset by peer
/home/travis/gopath/pkg/mod/github.com/lbryio/lbry.go@v0.0.0-20190109223729-30c312501602/extras/errors/errors.go:98 (0x526d75)
/home/travis/gopath/src/github.com/lbryio/reflector.go/peer/server.go:302 (0xb4691c)
/home/travis/gopath/src/github.com/lbryio/reflector.go/peer/server.go:164 (0xb45d85)
/home/travis/gopath/src/github.com/lbryio/reflector.go/peer/server.go:99

lyoshenka commented 5 years ago

@jackrobison still waiting for details from you

lyoshenka commented 5 years ago

assign it back to me after

jackrobison commented 5 years ago

@lyoshenka this seemed to be caused by something not being handled correctly when a connection is closed abruptly (while bytes are being written). It seems to be initiated during a download of a stream by the client downloading from reflector plus another fast peer, where the peer the blob downloads from oscillates between the two (and thus has a lot of cancellations mid-transfer). Another condition that may be required is where the stream is only partially uploaded to reflector (and had a similar mid-blob-upload cancellation)

jackrobison commented 5 years ago

A possible issue reproducing locally is that the local reflector.go blob server will reply (at least for me) with frames up to 262144 bytes long vs < 20000 bytes for the real one.

lyoshenka commented 5 years ago

The correct answer seems to be to just ignore these. They happen when the other side closes the connection without letting us know (because it has no way to let us know). Fixed in 7a618f4.