-
Notifications
You must be signed in to change notification settings - Fork 295
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
DLT-Multinode: Gateway does not recognize reset of passive node #551
Comments
Might be solved here: #537 I will test it... |
This does not solve the issue. |
Hello @marc-heinlein , |
Hello @michael-methner, the issue is when resetting the passive node. When resetting the gateway node, everything works like expected. |
Hi all, You can try to trigger an establishment from gateway to passive via dlt-passive-node-ctrl. |
Hmm, for me, it sounds strange, that the passive node should actively request at the gateway node to reconnect to passive node. If this is the forseen strategy for the multinode configuration, it should be built into the passive node, that it automatically (re-) requests the connection once the gateway node does not connect until a certain timeout (i. e. if the passive node restarts after a reset). Related to dlt-passive-node-ctrl: How could I call this on passive node side? I can not see any argument, that allows me to specify on which IP address the gateway node is located. Anyhow, this approach sounds to me like "create an external supervisor, for 'gateway-to-passive' connections". Overall, it would be more straight forward for the gateway node to just trigger reconnection once it detects, that the passive node is not there anymore (maybe a cyclic control message could be used for such an alive check). |
Hi dlt-passive-node-ctrl should be performed at gateway node not at passive. Regarding the automatically reconnect attempt from passive, from my point of view I think it is not reasonable. "create an external supervisor, for 'gateway-to-passive' connections". <== I would say yes for this point. |
Why not just letting the gateway node perform a (re-)connect as long as it detects, that it can not communicate with the passive node? This should be done independent of the reason of being disconnected:
|
Close due to being not a bug but specific DLT mechanism for gateway <-> passive node |
Unfortunately this issue has been closed considering to be a desired behaviour, that the gateway might loose the connection to a passive node without triggering any reconnection attempt. This somehow renders the DLT multinode approach for losely coupled nodes completely useless... Adding some external supervisor on the gateway node, that triggers the gateway to reconnect is a bad joke. |
Hi, In general, all features are very welcome and DLT maintainers are also happy and willing to review and Happy coding |
Hello all,
Sorry if there is static IPv6, I am testing IPv6 adaption for gateway.
On Docker:
On Host:
Result:
Same for the reverse way. My conclusion is that no matter how to disable the Gateway, or the Passive node, it will recover.
This is the result so far I check, please kindly check again.
|
Please notice that dlt is up to v2.18.10. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Precondition:
Action:
Expected behaviour:
Observed behavior:
Traces with Verbose=1 and LoggingLevel=7 are attached: dlt-log.zip
DLT Package Version: 2.18.9 STABLE, Package Revision: v2.18.9
The text was updated successfully, but these errors were encountered: