Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1258304

Summary: [GSS](6.4.z) Plain JMS clients don't fallback
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Tyronne Wickramarathne <tywickra>
Component: HornetQAssignee: jboss-set
Status: CLOSED NOTABUG QA Contact: Miroslav Novak <mnovak>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.4.3CC: bmaxwell, csuconic, dtikhomi, egonzale, jmesnil, jpallich, jtruhlar, msvehla, remerson, rpelisse, tywickra
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-09-15 15:43:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
reproducer - configuration files none

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