 |
Search |
 |
|
|
JMS Service Availability in GlassFish V2Posted by rampsarathy on February 17, 2007 at 8:36 PM PST
JMS Service Availability in GlassFish V2Availabilty 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 :
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
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.
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
References
|
|
|
||
|
