Update client addressList when a GlassFish-managed broker is added/removed to/from the cluster

[glassfishrobot]

This feature request describes code changes to ensure that when a broker is added to, or removed from, a conventional broker cluster being managed by GlassFish, the addressList property used by all existing and future connections to that cluster are updated to reflect the addition or removal of the broker. This means that in the event of a broker failure each connection to that broker can failover to any of the remaining brokers in the cluster, and that time is not wasted trying to failover to brokers that no longer exist.

For full and definitive detail of this feature please see the appropriate one-pager, which overrides the any detail included in this JIRA issue.

This change is needed to support the elasticity of managed MQ brokers in GlassFish 3.2.

The basic requirement here is to ensure that client connections to clustered brokers always hold an up-to-date list of the brokers in the cluster in order to ensure that in the event of connection failure the connection can failover to any of the remaining brokers in the cluster, and that time is not wasted trying to failover to brokers that no longer exist.

This requirement only applies in the following case:

• Where the brokers in the cluster have their lifecycle managed by GlassFish. (Although similar behaviour would be desirable for non-managed broker clusters, this is not currently a requirement.)
• Where the client connections are running in GlassFish and created using the JMSRA resource adapter. (Although similar behaviour would certainly be desirable for standalone client connections using the MQ client, this is outside the scope of this one-pager.)
• For conventional clusters. (This behaviour is already available when using enhanced clusters, which are "self-configuring" and each client is automatically updated to hold an up-to-date list of the brokers in the cluster.)

In the standalone MQ client, the list of brokers in the cluster is set using the connection factory attribute imqAddressList. However where the client connection is created using the JMSRA resource adapter this property is set not by users but by JMSRA using the resource adapter property connectionURL, which may be overridden by setting the addressList property on an individual managed connection factory or activation spec.

Here is a summary of the existing behaviour in GlassFish 3.1 when using a conventional cluster:

• When each GlassFish instance is started, the GlassFish JMS module sets the following properties on the JMSRA resource adapter. Note that these two properties are similar but not the same:
  • connectionURL is set to a comma-separated list that defines the addressing scheme, host and port for each broker in the cluster. For example: mq://machine1:7676/jms,mq://machine2:7676/jms. The local broker should be the first in this list. JMSRA uses this property to set the imqAddressList of any connections made to that broker, unless it has been overridden by setting the addressList property on an individual managed connection factory or activation spec.
  • clusterBrokerList is set to a comma-separated list of brokers in the cluster. For example: machine1:7676,machine2:7676. JMSRA uses this property to set the imq.cluster.brokerlist property of the managed local or embedded broker, both when it is first startedand when a local broker is restarted.
• Whenever an instance is added to, or removed from, the GlassFish cluster, the GlassFish JMS module updates the clusterBrokerList of every resource adapter instance in the cluster with the new list of brokers. The RA uses this information only if it is managing a embedded or local broker, and uses it for the following purpose:
  • It will save this information and use it to set imq.cluster.brokerlist when starting a managed (local or embedded) broker or when restarting a local broker.
  • It uses a private protocol to send this information to the broker in order to update its imq.cluster.brokerlist property.

Important: Note that if cluster elasticity is required when the brokers are remote (which is explicitly out of scope for this one-pager), GlassFish must also set or update the clusterBrokerList in this case.

Although the above behaviour will ensure that the brokers have an up to date imq.cluster.brokerlist there is currently no mechanism to ensure that existing and future connections have an up to date addressList. To achieve this the following additional behaviour is required:

• Whenever an instance is added to, or removed from, the GlassFish cluster, the GlassFish JMS module updates the connectionURL of every resource adapter instance in the cluster to reflect the added or removed broker. The RA will use this information only if it is managing a embedded or local broker, and uses it for the following purpose:
  • It will save this information and use it to set imqAddressListlist of any connections that are subsequently created unless it was overridden by setting the addressList property on an individual managed connection factory or activation spec.
  • It uses it to update the imqAddressListlist of any existing connection factories.
  • It uses a private protocol to send this information to the broker, which will then sent it to all its connected clients to update their imqAddressListlist,

Important: Note that if cluster elasticity is required when the brokers are remote (which is explicitly out of scope for this one-pager), GlassFish must also set or update the connectionURL in this case. TODO: Define private protocol by which RA sends connectionURL to broker, and broker sends imqAddressListlist to existing connections.

Affected Versions

[4.1, 4.2, 4.3, 4.4, 4.4u1, 4.4u2, 4.5, 4.5.1, 4.5.2]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/openmq/issues/91
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @edbratt

[glassfishrobot]

@glassfishrobot Commented Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: This new feature is not a requirement of GlassFish 4.0, so I'm changing the target version to 5.1.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA MQ-91