Bug 1267172 - [GSS](6.4.z) Rebalance RA Connections after new cluster nodes
Summary: [GSS](6.4.z) Rebalance RA Connections after new cluster nodes
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: HornetQ
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: CR1
: EAP 6.4.6
Assignee: Dmitrii Tikhomirov
QA Contact: Miroslav Novak
URL:
Whiteboard:
: 1261984 (view as bug list)
Depends On:
Blocks: 1235746 1274290
TreeView+ depends on / blocked
 
Reported: 2015-09-29 08:45 UTC by Tom Ross
Modified: 2019-10-10 10:15 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-17 11:46:54 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker HORNETQ-1495 0 Major Resolved Rebalance RA Connections after new cluster nodes 2020-10-16 14:52:27 UTC
Red Hat Issue Tracker HORNETQ-1499 0 Major Resolved Rebalance JCA RA inflow connections when cluster topology changes 2020-10-16 14:52:27 UTC
Red Hat Issue Tracker JBEAP-1758 0 Major Closed Rebalance Artemis JCA RA inflow connections when cluster topology changes 2020-10-16 14:52:27 UTC
Red Hat Knowledge Base (Solution) 2139541 0 None None None 2016-01-26 09:46:42 UTC

Description Tom Ross 2015-09-29 08:45:40 UTC
HornetQ RA should be able to connect to new cluster members when they join a HornetQ cluster. At the moment, when a HornetQ RA which is configured with two static connectors pointing at remote HornetQ cluster, is started  it will connect all its connection only to nodes that are running in the remote cluster.  If there are nodes that join the remote cluster later, the RA will never connect to them.
It should be possible for the RA the change in cluster topology when new members are joining and rebalance its connections in such way that they are evenly spread among all cluster members.
When rebalancing is being performed, RA should allow for _graceful_ shutdown of existing connections that is any outstanding transactions should be allow to complete.
RA should provide an option for _hard_ shutdown if transactions do not complete within specified  time out (configurable)  

Step to reproduce:

Create a two node HornetQ cluster (JMSProvider-cluster) with a testQueue.
Create a two node HornetQ cluster (ApplicationProvider-cluster)
Configure HornetQ-Remote RA that points at JMSProvider-cluster.
Start ApplicationProvider-cluster
Deploy MDB on ApplicationProvider-cluster that listens on remote testQueue in JMSProvider-cluster and uses HornetQ-Remote RA
Start node one in JMSProvider-cluster. After the node is started it should be possible to see in all connections for HornetQ-Remote RA have been allocated to that node for testQueue.
Start second node in JMSProvider-cluster. After the node is started it is possible to see that there are no connections on that node for HornetQ-Remote RA on testQueue.

Comment 1 JBoss JIRA Server 2015-12-11 20:28:37 UTC
Justin Bertram <jbertram> updated the status of jira HORNETQ-1495 to Resolved

Comment 3 Miroslav Novak 2016-01-19 14:55:01 UTC
Setting as verified with EAP 6.4.6.CP.CR2.

Comment 4 Bartek Spyrko-Smietanko 2016-03-31 18:47:21 UTC
*** Bug 1261984 has been marked as a duplicate of this bug. ***

Comment 5 Petr Penicka 2017-01-17 11:46:54 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 6 Petr Penicka 2017-01-17 11:47:57 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.


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