JMS Service Availability in GlassFish V2

Posted by rampsarathy on February 17, 2007 at 11:36 PM EST

Availabilty is the proportion of time a system is in a functioning condition (Wikipedia). It is a vital requirement for any enterprise application.This article talks about how jms service availability can be guaranteed for applications deployed on GlassFish and SJSMQ. GlassFish V2 allows users to create application server clusters, applications that are deployed to a cluster are deployed to all instances in the cluster and remain available even if one or more instances in the cluster fail. GlassFish V2 (Build 33) uses Sun Java System Message Queue (SJSMQ) 4.1 (https://mq.dev.java.net) as the default JMS provider. SJSMQ 4.1 supports clustering with two levels of availabilty :

Service Availability: A JMS service that is always available, but one is not necessarily concerned if messages are unavailable for some amount of time, or possibly even lost. Often used by event based systems sending non-persistent messages. If a message broker instance goes down, the applications simply need to failover to some other broker where they can continue to send and receive messages. If some events are lost (or become unavailable), that's OK.
Data Availability: Service Availability, plus availability of persistent messages, and JMS semantics (i.e. message order, one-and-only-once delivery) preserved on those messages.

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) 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 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.

Configuring Application server cluster with multi-broker cluster (REMOTE mode) :

The deployment planning guide here 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.

Out-of-the-box jms service availability using GlassFish Clusters (LOCAL mode) :

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

List of brokers that will participate in the cluster
The master broker in the cluster.

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 :

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.

Creates a cluster with name cluster.name (cluster1)
- asadmin create-cluster --user admin --passwordfile adminpassword.txt
  --host localhost -port 4848 cluster1

Creates a node-agent with name

nodeagent.name
(cluster1-nodeagent)

asadmin create-node-agent --user admin --passwordfile adminpassword.txt 
 --host localhost -port 4848 cluster1-nodeagent

Starts the node-agent

asadmin start-node-agent --user admin --passwordfile adminpassword.txt
 --host localhost -port 4848 cluster1-nodeagent

Creates two instances under the cluster that will use the node agent just created

asadmin create-instance --user admin --passwordfile
adminpassword.txt --host localhost -port 4848
 --cluster cluster1 --nodeagent cluster1-nodeagent 
--systemproperties"JMX_SYSTEM_CONNECTOR_PORT=8687:IIOP_LISTENER_PORT=3330:
IIOP_SSL_LISTENER_PORT=4440:IIOP_SSL_MUTUALAUTH_PORT=5550:HTTP_LISTENER_PORT=1110:
HTTP_SSL_LISTENER_PORT=2220" instance-ONE

asadmin create-instance --user admin --passwordfile
adminpassword.txt
--host localhost -port 4848 --cluster cluster1 
--nodeagent cluster1-nodeagent
 --systemproperties "JMX_SYSTEM_CONNECTOR_PORT=8688:IIOP_LISTENER_PORT=3331:
IIOP_SSL_LISTENER_PORT=4441:IIOP_SSL_MUTUALAUTH_PORT=5551:HTTP_LISTENER_PORT=1111:
HTTP_SSL_LISTENER_PORT=2221"instance-TWO

Starts the cluster

asadmin start-cluster --user admin --passwordfile adminpassword.txt 
--host localhost -port 4848 cluster1

References

1. MQ integration changes in GlassFish :
   www.glassfishwiki.org/gfwiki/attach/UserExperienceMeeting/gfv2-as_mq_integration-user-experience.odp
2. Multi-broker cluster REMOTE configuration :
    http://docs.sun.com/app/docs/doc/819-2560/6n4rejb1h?a=view
3. Mesage Queue
   https:// mq.dev.javanet

Comments

Hi, I'm a newbie and I'm

by emanuelecar - 2010-06-09 08:36

Hi, I'm a newbie and I'm trying to start a glassfish (v 2.1.1)cluster using the "out-of-the-box solution", but I don't know how to setup the borkerlist and the master borker (I've also read the docs and the guide but it's a bit confusing) before starting the cluster. Would you mind to give some help? Thank you.

EMBEDDED type in cluster?

by yuyuchen09 - 2010-07-22 21:24

I understand in LOCAL mode, glassfish supports auto-clustering which starts a non-HA broker cluster; and in REMOTE type, it can operate with a HA broker cluster; Now, neither this doc nor the official HA doc mention the EMBEDDED mode, which is the mode our web/MDB app use when deployed in a standalone app server. My question is, Is EMBEDDED JMS supported in glassfish cluster? In this JMS type, each app server instance has a MQ broker co-located in the same JVM, now, are these MQ brokers cluster-aware? Do they form a broker cluster as in a LOCAL mode? Thanks!

JMS in cluster mode issue

by saikiranreddy - 2010-04-12 00:18

Hi, I am using JMS in cluster mode for my project.(Local mode) When ever i post a message to JMS queue, is there a possibility that this massage is handled by the other instance in the cluster? Simillarly, i am running different cluster instances in different JVMs. so if i post a message to a JMS queue in one cluster , is there a possibility that the message is be handled by the other cluster? Regards Kiran

The local mode cluster tries

by rampsarathy - 2010-04-12 00:47

The local mode cluster tries to ensure message colocation, i,e if you re sending a message from cluster instance1, then it will be consumed by the consumer in instance1 , typically true of an MDB scenario where an EJB/Servlet sends a message and an MDB is invoked.. If a message is sent from a client outside (the server VM), the it could be received by any of the instances in the cluster. Depends on where the message is sent from...

Hi Ram, I am using the

by saikiranreddy - 2010-07-14 03:26

Hi Ram, I am using the default JMS Host & default MQ broker with MQ & AS relationship as LOCAL. U mean to say that in this setup, the mesasges produced on a node will be handled by the consumer/listener on the same node. What happens if i use cluster MQ broker? Regards Saikiran

Main Menu

Ramesh Parthasarathy

JMS Service Availability in GlassFish V2