Bug 1258304 - [GSS](6.4.z) Plain JMS clients don't fallback
Summary: [GSS](6.4.z) Plain JMS clients don't fallback
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ
Version: 6.4.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: jboss-set
QA Contact: Miroslav Novak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-31 03:37 UTC by Tyronne Wickramarathne
Modified: 2019-11-14 06:55 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-15 15:43:38 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
reproducer - configuration files (8.19 KB, application/x-bzip)
2015-08-31 03:43 UTC, Tyronne Wickramarathne 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBEAP-4477 0 Major Closed Plain JMS clients don't fallback 2017-05-02 09:41:28 UTC
Red Hat Issue Tracker WFLY-5970 0 Major Resolved Plain JMS clients don't fallback 2017-05-02 09:41:28 UTC

Description Tyronne Wickramarathne 2015-08-31 03:37:05 UTC 
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-31 03:43:22 UTC 
Created attachment 1068504 [details]
reproducer - configuration files
Comment 13 JBoss JIRA Server 2016-06-09 08:08:30 UTC 
Enrique González Martínez <elguardian> updated the status of jira WFLY-5970 to Reopened
Comment 16 Jeff Mesnil 2016-09-15 12:39:01 UTC 
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 12:49:00 UTC 
Jeff Mesnil <jmesnil> updated the status of jira WFLY-5970 to Closed
Comment 18 JBoss JIRA Server 2016-09-15 12:49:07 UTC 
Jeff Mesnil <jmesnil> updated the status of jira WFLY-5970 to Reopened
Comment 19 JBoss JIRA Server 2016-09-15 12:49:38 UTC 
Jeff Mesnil <jmesnil> updated the status of jira WFLY-5970 to Resolved
Comment 20 Jeff Mesnil 2016-09-15 12:58:44 UTC 
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 15:43:38 UTC 
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.