Skip to main content

JMS Service Availability in GlassFish V2

Posted by rampsarathy on February 17, 2007 at 8:36 PM PST

JMS Service Availability in GlassFish V2

JMS Service Availability
in GlassFish

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
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. href="">GlassFish V2
uses Sun Java System Message Queue (SJSMQ) 4.1 ( href="">
as the default JMS
provider.   SJSMQ 4.1 supports clustering with two
levels of availabilty :

style="font-weight: bold; background-color: rgb(204, 204, 255);">
style="background-color: rgb(204, 204, 255); text-align: justify;">
  • Service Availability: style="font-weight: bold;"> A JMS service that
    is always
    available, but one is not necessarily concerned if messages are
    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, plus
    availability of persistent messages, and JMS semantics
    (i.e. message order, one-and-only-once delivery) preserved on those
  • 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
    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
    link describes the clustering (for
    service availability) support in SJSMQ (3.6 onwards) href="">

     This post describes few steps to
    enable jms service availability
    in GlassFish V2.  Data Availabilty configuration, though
    (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="">
    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 href="">
    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
    is taking a first look at using service availability.

    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
    , these are
    1. List of brokers that will participate in the cluster
    2. 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 :

    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.

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

    style="margin-left: 40px; background-color: rgb(204, 204, 204); text-align: justify;">
  • Creates a cluster with name
    • asadmin create-cluster --user admin --passwordfile adminpassword.txt
      --host localhost -port 4848 cluster1
  • Creates a node-agent with name
    • 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
      HTTP_SSL_LISTENER_PORT=2220" instance-ONE 
    • asadmin create-instance --user admin --passwordfile
      --host localhost -port 4848 --cluster cluster1
      --nodeagent cluster1-nodeagent
      --systemproperties "JMX_SYSTEM_CONNECTOR_PORT=8688:IIOP_LISTENER_PORT=3331:
  • Starts the cluster
    • asadmin start-cluster --user admin --passwordfile adminpassword.txt
      --host localhost -port 4848 cluster1


    Related Topics >>


    Hi, I'm a newbie and I'm

    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.

    JMS in cluster mode issue

    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

    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

    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