If a clustered HornetQ instance lost its connection to other cluster nodes, reconnection attempts could result in an infinite loop. For a static cluster configuration, any initial connect attempt would be attempted infinitely, ignoring the `reconnect-attempts` parameter. For a dynamic cluster configuration, if the node was disconnected between the time it received a notification about the node being part of the cluster topology and the initial connection, reconnection attempts continued infinitely. This issue has been resolved and the clustering logic now uses the `reconnect-attempts` parameter for both the initial connection attempts and reconnection attempts.
Cluster connection bridge should use the "reconnect-attempts" value for both the initial connection attempts and reconnection attempts.
Fix committed to the 2.3.x branch. See https://github.com/hornetq/hornetq/commit/8ef706763c784aebc43c1b4aa3dfc309122f5f2d.
Setting to ON_QA since upgrade should fix this
do we have a way to reproduce this issue. I did some tries with debugger but without success. Can you help, please?
It can't easily be produced without a debugger https://issues.jboss.org/browse/HORNETQ-1306 provides the steps.
Thanks Shaun! I'll give it a try.
Fix is not present in HornetQ tag HornetQ_2_3_18_Final which is in EAP 6.3.0.ER3. (It seems that it was merged just to master but not to 2.3.x branch.)
This fix also requires update of xsd schema so attribute "initial-connect-attempts" can be set in standalone...xml and domain.xml.
Ignore my comment above. Attribute "reconnect-attempts" defines initial retry. I've managed to reproduce the issue and don't see the described problem again when "reconnect-attempts" is set to 3 in cluster-connections.