Red Hat Bugzilla – Bug 1258304
[GSS](6.4.z) Plain JMS clients don't fallback
Last modified: 2016-10-24 09:09:46 EDT
Description of problem:
Plain JMS clients don't fallback when the Live server takes over
Version-Release number of selected component (if applicable):
HornetQ - 2.3.25.SP3
Steps to Reproduce:
1. Configure a live-backup pair on the same machine with a shared store in standalone mode
2. Please change the default cluster configuration to use netty connectors instead of the default UDP
3. Start the live node then the backup node
4. Start a plain JMS consumer and a producer
5. Please configure the producer to send 20,000 messages at 1.5 second intervals
6. Stop the live server using Ctrl + C
7. The clients would fail over to the backup node (the new active node)
8. Please wait about 20 seconds
9. Start the live server.
10. The live server becomes active and the backup node goes back to the passive mode
11. The clients would not failback to the live node.
12. The JMS clients remain in hung state indefinitely
The JMS clients remain in hung state indefinitely
The clients need to fallback to the live node when the live node comes online and active again.
Created attachment 1068504 [details]
reproducer - configuration files
Enrique González Martínez <firstname.lastname@example.org> updated the status of jira WFLY-5970 to Reopened
I've nacked this issue.
The configuration is not correct as howard already stated. A <netty-connector> must be used, not a <connector>.
The generic <connector> is meant to be used when the type of connection factory is neither netty nor invm (which is almost never the case).
If the user wants to use a remote connector, he must use a <netty-connector>.
Jeff Mesnil <email@example.com> updated the status of jira WFLY-5970 to Closed
Jeff Mesnil <firstname.lastname@example.org> updated the status of jira WFLY-5970 to Reopened
Jeff Mesnil <email@example.com> updated the status of jira WFLY-5970 to Resolved
there is a related minor issue that was fixed in EAP7 (https://issues.jboss.org/browse/WFLY-5394) but the main point is that users should use a <netty-connector> instead of a generic <connector> using the org.hornetq.core.remoting.impl.netty.NettyConnectorFactory class.
Closing as per comments above, this was a configuration issue