-
Notifications
You must be signed in to change notification settings - Fork 896
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate Connect/Disconnect Events Ordering #4091
Comments
it broke some ATs but it works locally with my 3 nodes setup trying this one out in goerli #4100 |
Running up RC2 (with and without this change #4100) on local setup, goerli and mainnet to see if the "stale disconnected peers" is still a problem. |
Locally - RC2 locally with besu-local-nodes setup (3 x besu, one is a bootnode for the other 2) - I still get the stale disconnected duplicate every time (on the bootnode)
|
mainnet with RC2
This grep for validated false does return some stale peers - but again, they are transient.
~20 unique stale peers - but all with validated = false
latest contents of EthPeers. max size I have seen is 26.
|
goerli with RC2
and the results in sorted.txt are 50/50 responses from disconnected peers and stale disconnected peers
|
goerli with 4100
It's about 70/30 stale peers and responses
latest contents of EthPeers
|
^ in both cases on goerli I can see the stale peers in the logs but they don't persist, and the size doesn't grow over time. They do eventually get removed. Max size I have seen is 26. |
Closing this one - conclusion is that there isn't a problem on mainnet/goerli |
This may help identifying the problems with #2689
Per @mbaxter's comment:
There could be a race condition wrt how connect and disconnect events are dispatched. For example, say we’re in the process of handling a new connection and in another thread, we receive a disconnect message from the newly connected peer. Is it possible we’re dispatching the disconnect event before the connection event? This would cause stale, disconnected peers to persist in the EthPeers collection. If this is actually the issue, it should be possible to rework disconnect events so that they are only dispatched after the connection event is dispatched.
The text was updated successfully, but these errors were encountered: