Bug 1258304 - [GSS](6.4.z) Plain JMS clients don't fallback
[GSS](6.4.z) Plain JMS clients don't fallback
Status: CLOSED NOTABUG
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ (Show other bugs)
6.4.3
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: jboss-set
Miroslav Novak
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-30 23:37 EDT by Tyronne Wickramarathne
Modified: 2016-10-24 09:09 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-15 11:43:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproducer - configuration files (8.19 KB, application/x-bzip)
2015-08-30 23:43 EDT, Tyronne Wickramarathne
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBEAP-4477 Major Closed Plain JMS clients don't fallback 2017-05-02 05:41 EDT
JBoss Issue Tracker WFLY-5970 Major Resolved Plain JMS clients don't fallback 2017-05-02 05:41 EDT

  None (edit)
Description Tyronne Wickramarathne 2015-08-30 23:37:05 EDT
Description of problem:
Plain JMS clients don't fallback when the Live server takes over

Version-Release number of selected component (if applicable):
JBoss-EAP-6.4.3
HornetQ - 2.3.25.SP3

How reproducible:
Always

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 



Actual results:
The JMS clients remain in hung state indefinitely 


Expected results:
The clients need to fallback to the live node when the live node comes online and active again.

Additional info:
Comment 1 Tyronne Wickramarathne 2015-08-30 23:43:22 EDT
Created attachment 1068504 [details]
reproducer - configuration files
Comment 13 JBoss JIRA Server 2016-06-09 04:08:30 EDT
Enrique González Martínez <elguardian@gmail.com> updated the status of jira WFLY-5970 to Reopened
Comment 16 Jeff Mesnil 2016-09-15 08:39:01 EDT
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>.
Comment 17 JBoss JIRA Server 2016-09-15 08:49:00 EDT
Jeff Mesnil <jmesnil@redhat.com> updated the status of jira WFLY-5970 to Closed
Comment 18 JBoss JIRA Server 2016-09-15 08:49:07 EDT
Jeff Mesnil <jmesnil@redhat.com> updated the status of jira WFLY-5970 to Reopened
Comment 19 JBoss JIRA Server 2016-09-15 08:49:38 EDT
Jeff Mesnil <jmesnil@redhat.com> updated the status of jira WFLY-5970 to Resolved
Comment 20 Jeff Mesnil 2016-09-15 08:58:44 EDT
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.
Comment 22 Brad Maxwell 2016-09-15 11:43:38 EDT
Closing as per comments above, this was a configuration issue

Note You need to log in before you can comment on or make changes to this bug.