py-evm: Trinity logs lots of "socket.send() raised exception" warnings
on current master @ 32cc41d5315003289b1c86b31680f2501894da06
What is wrong?
When running trinity a lot of these warnings happen.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
WARNING 07-14 03:48:12 selector_events socket.send() raised exception.
How can it be fixed
It looks like it may related to this issue found here on stack overflow:
https://stackoverflow.com/questions/32175217/how-to-detect-write-failure-in-asyncio
However, brief experimentation with adding a await asyncio.sleep(0) to the only place in our code that calls writer.drain() didn’t fix anything…
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (9 by maintainers)
Commits related to this issue
- PeerPool is now an asynchronous iterator This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterator This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to gsalgado/py-evm by gsalgado 6 years ago
- PeerPool is now an asynchronous iterable This way callsites are less likely to get a list of peers and hold them while making blocking calls, as these peers may disconnect in the meantime. Closes: #... — committed to ethereum/py-evm by gsalgado 6 years ago
@carver
I think this is part of the solution, however, I believe what we’re seeing is a race condition where the peer is connected at the start of the tx pool send loop, but by the time that it comes time to send to that peer they have disconnected.