You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
Since upgrading to 1.0.0 (from 0.8) the nodes seem to store their previous peers into the
launcher-configuration.ini
.The
bootstrap
sectionseems 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.
The text was updated successfully, but these errors were encountered: