JMS Service Availability in GlassFish V2

Though
Data Availability provides true availability ( both
service and message) , it (the brokers in the cluster)
requires a highly available shared persistent store (Database) to store
the
in-transit messages (along with other message attributes), so that
messages can be taken over by any instance
in case of a failure. Service availability is easy to achieve and
relies on the broker's ability to form master-slave or peer-peer
clusters. Service availability in SJSMQ can be achieved by creating a
broker cluster based on master broker architecture.  The
following
link describes the clustering (for
service availability) support in SJSMQ (3.6 onwards) href="http://docs.sun.com/source/819-2574/broker_clusters.html">http://docs.sun.com/source/819-2574/broker_clusters.html



 This post describes few steps to
enable jms service availability
in GlassFish V2.  Data Availabilty configuration, though
possible
(using MQ 4.1),
is out of scope of this document.



GlassFish offers different ways by which a jms
provider can be
integrated, please refer to href="http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=AppserverMqIntegrationOptions">http://www.glassfishwiki.org/gfwiki/Wiki.jsp?page=AppserverMqIntegrationOptions
for all the available options and what they mean. The type of
integration determines how the lifecycle of the message broker is
managed by the application server.



    - LOCAL mode -
The application server starts the MQ
broker in a separate process, the broker process is started when the
application server starts up and is shutdown when the application
server is stopped. The lifecycle of the broker is controlled by the
application server.

    -
REMOTE  mode - The broker has to be started
separately by the JMS administrator, the broker details (host, port,
user name and password) are configured in the application server. The
AS pings the broker to check if its up when it starts  up.



The mode of integration of the jms-service
(LOCAL or REMOTE) can be
configured through the GlassFish adminintration console or the asadmin
CLI tool using the set command. Each integration mode has its own
advantages and disadvantages.

The deployment planning
guide here href="http://docs.sun.com/app/docs/doc/819-2560/6n4rejb1h?a=view">http://docs.sun.com/app/docs/doc/819-2560/6n4rejb1h?a=view
describes how
a broker cluster
can be can be used with an application server cluster. This form of
service availability is available since Sun Java System Application
Server 8.1 (EE).

Since this requires
significant configuration changes that have to
performed manually both by the JMS administrator and the application
server administrator, it is pretty demanding for a  developer
who
is taking a first look at using service availability.

   
One of the feature that has been added to GlassFish
V2 Milestone 4(b33) is behind the scene broker cluster creation
(configuration) when a application server cluster is created. The
default integration mode for a cluster instance in GlassFish is LOCAL,
and every application server instance in the cluster has a LOCAL
co-located broker ( broker started in a separate process). When the
cluster starts up, all the broker instances associated with the
application server instances are also started up (LOCAL mode, lifecycle
is managed by the server).  These brokers are started in a
cluster-aware fashion so that service availability is available by
default when a cluster is started up, without the need for any extra
configuration. To start the brokers in a clustered mode, the following
information has to be supplied as arguments  to
the
broker, these are

The logic for
determining the above is built into the application
server and requires no explicit configuration from the user. Since each
application server instance in the cluster has exactly one collocated
broker that is managed by it,  a cluster with N instances will
have N
separate broker instances. When the application server cluster is
started a broker cluster (with N pariticipating brokers) has to be
started in parallel. This is achieved by creating a list (connection
url) of all the brokers, and starting each broker with this list. Also,
the broker that that is associated with the very first instance of the
application server cluster (when it was created) is designated as the
master broker. The broker id and the cluster name for the broker
cluster are generated dynamically.

The following features are available to developers, without having the
need to perform any configuration :



style="font-weight: bold;">Sticky connections using priority
addresslist behavior : Applications deployed
on instance X of
the cluster will always use the co-located broker of instance X for
their jms messaging needs. This is ensured by exploiting the priority
behavior, adjusting the addresslist order and placing the co-located
broker's address always at the begining, this way a JMS connection is
always established with the co-located broker. Apart from providing
stickiness this also ensures that connections from application
instances are balanced across brokers.

Fail
over :
In the event of a
broker failure, the connection is automatically established with the
next broker in the address list. In the outbound path this is achieved
by setting the ConnectionValidationEnabled flag in the connectoion
factory and the failallconnections connection pool property to true.
When  a connection is lost with the broker because of
broker/network failure, all connections in the pool are discarded
and  a new connection is established with the next available
broker in the list.  This way the jms service is available to
all
the applications (in all the instances) as long as there is one active
broker in the cluster. For inbound connections fail over is
accomplished by setting the reconnectEnabled and reconnecAttempts flags.

cluster.name
(cluster1)

nodeagent.name
(cluster1-nodeagent)