Closed GoogleCodeExporter closed 9 years ago
Eww, these Netty stack traces are just ridiculous. I hope Netty 4 can fix some
of these problems.
In this case the issue is not only Netty internal locks, but also unexpected
re-entrancy. Attempting to send a message as part of switching download peer
triggers a recursive re-entry via Channels.write(). It will take a bit of time
to study this and figure out how it happened: looks like Channels.write() can
make almost anything happen!
Original comment by hearn@google.com
on 5 Apr 2013 at 9:29
I think the problem is that something bad happened that caused the remote peers
to hang up on us, so when we picked a new download peer and tried to talk to
it, that led to it also being terminated and we ended up recursively trying to
close peers/pick new download peers.
One question is why so many peers died simultaneously. But it's academic, this
situation can happen and needs to be handled appropriately.
Another question is the what the right fix is. Possibly trying to do too much
work on an IO thread directly isn't the right approach and picking download
peers is best done by a separate thread. But then again, Channels.write() on
the closed peer would result in similar sorts of call stacks no matter what.
Original comment by hearn@google.com
on 5 Apr 2013 at 10:18
netty is gone
Original comment by hearn@google.com
on 12 Dec 2013 at 3:05
Original issue reported on code.google.com by
murexcon...@googlemail.com
on 3 Apr 2013 at 9:14