Skip to content
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

Startup deadlocks in network synchronization #74

Open
ThoreKr opened this issue Dec 13, 2020 · 1 comment
Open

Startup deadlocks in network synchronization #74

ThoreKr opened this issue Dec 13, 2020 · 1 comment

Comments

@ThoreKr
Copy link
Contributor

ThoreKr commented Dec 13, 2020

Since upgrading to 1.0.0 (from 0.8) the nodes seem to store their previous peers into the launcher-configuration.ini.
The bootstrap section

[bootstrap]
192.168.178.28:9012

seems to be evaluated either way (even when providing -b) and if one of the nodes doesn't exist any more the synchronization doesn't finish. Even worse, when restarting the entire network. the node intended to be the bootsrap node tries to reach its previous peers, which again are trying to reach the bootstrap node resulting in a deadlock until the file ore the config section is manually deleted.

@ThoreKr
Copy link
Contributor Author

ThoreKr commented Dec 19, 2020

So, to further elaborate these findings.

This does not happen when making sure a node has properly left the network after shutdown, (even when using quit) it takes about a minute for the node to no longer be listet in getNetInfo.
Then both nodes will start up and synchronise again.

For development this is not really convenient. The pragmatic approach is to extend my local start script with an rm instruction.

However, I'm still unsure if this can lead to unexpected behaviour. I've been able deadlock two out of three services by simultaneously restarting them. But just once.
In all except this one case it was possible to kill and restart services as long as one remained available.

So it seems to work as intended except for the seed node. Would it make sense to ignore the bootstrap config section when -b isn't specified?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant