This discussion is archived
4 Replies Latest reply: Dec 21, 2012 12:08 PM by Tom B RSS

jms order of message delivery with high availability

balajraj_oracle Newbie
Currently Being Moderated
I have set up uniform distributed queue with weblogic server 12c. I am trying to achieve order of delivery and high availability with jms distributed queue. In my prototpe testing deployment I have two managed servers in the cluster, let us say managed_server1 and managed_server2. Each of this managed server hosts jms server namely jms server1 and jms server2. I have configured the jms servers with jdbc persistent store. I have enabled server affinity.

1. I have a producer running such as java queuproducer t3::/managed_server1. I send out 4 messages. From the weblogic monitoring console I see there are 4 messages in the queu since there are no consumers to the queue yet.
2. Now I shut down managed_server1.
3. Bring up a consumer to listen on java queuconsumer t3://managed_server2. This consumer cannot consume message since the producer send all the messages to jms server1, and it is down.
4. Bring up managed server 1, start a consumer to listen to t3://managed_server1 I can get all messages.

Here is my problem say if the managed_server1 went down then there it never came back up, do i loose all my messages. Also if there is another producer sending messages to java queuproducer t3://managed_server2 then order of messages based on the time between these producers are not guanranteed.

I am a little lost, am I missing something. Can unit of order help me to overcome this. Or should I use distributed topic instead of distributed queue, where all the jms server will receive all the messages from producers, but if one jms server where my consumre is listening fails there is only one consumer in my application, when I switch over to other jms server, I might be starting to get messages from the beginning not from where I left off.

Any suggestions regarding the same will be helpful.
  • 1. Re: jms order of message delivery with high availability
    Fabian Pro
    Currently Being Moderated
    Hi,

    As you said,You have 2 managed servers in a cluster example 1.1.1.1:7200 and 2.2.2.2:7200
    Each Managed server hosts jms server namely jms server1 and jms server2(here let jms server 1 and 2 point to migrate able targets)
    So now you have created a uniform distributed queue,Target this queue to both the JMS Servers ie 1 and 2

    At Coding end,It would look like below
    <void method="put">
    <string>queueJNDI</string>
    <string>Your_JNDI_Name</string>
    </void>
    <void method="put">
    <string>providerURL</string>
    <string>t3://1.1.1.1:7200,2.2.2.2:7200</string>
    </void>

    Regards
    Fabian
  • 2. Re: jms order of message delivery with high availability
    RenévanWijk Oracle ACE
    Currently Being Moderated
    "
    1. I have a producer running such as java queuproducer t3::/managed_server1. I send out 4 messages. From the weblogic monitoring console I see there are 4 messages in the queu since there are no consumers to the queue yet.
    2. Now I shut down managed_server1.
    3. Bring up a consumer to listen on java queuconsumer t3://managed_server2. This consumer cannot consume message since the producer send all the messages to jms server1, and it is down.
    4. Bring up managed server 1, start a consumer to listen to t3://managed_server1 I can get all messages.
    "

    When you shutdown managed server1, the jms server targeted to managed server 1 is not available as well (your point 3). What you can do
    in this case is target the JMS Server to a migratable target and configure the migration, an example is provided here - http://middlewaremagic.com/weblogic/?p=7188

    As you want to message to be processed in order, you need to do something extra here as well, for example, unit of order.

    Ordered processing requires the following:
    - A single consumer which processes the messages.
    - Set the maximum messages per session attribute of the connection factory to 1.
    - Ensure that all messaging that require ordering go to the same destination.
    - Do not use custom destination ordering that change the default FIFO ordering.
    - Do not set redelivery delays.

    Unit-of-order is most commonly used with queues. While it can be used with topics, care must be taken when the message consumers are message-driven beans.
    Message-driven beans that do not use container-managed transactions multiplex the messages from a topic subscription across multiple message-driven bean instances,
    thus processing the messages in parallel. This feature is useful to speed up message processing but it does not take into account any unit-of-order. We must disable
    this parallel processing to preserve the order by either using container-managed transactions or by setting max-beans-in-free-pool to 1 in the deployment override
    weblogic-ejb-jar.xml. When producing unit-of-order messages to a distributed topic, we must target the distributed topic itself. Unlike other JMS messages, sending
    unit-of-order messages directly to a member topic is not recommended and may cause messages to be delivered out of order. Sending the messages directly to the
    distributed topic is the natural approach so this restriction should not cause any problems.

    How does WebLogic know which member destination to use when multiple producers are sending messages associated with the same unit-of-order to a distributed
    destination? WebLogic supports two routing mechanismsto accomplish this: path service based routing and hash-based routing.

    Path service is a singleton service that runs on one server in the cluster and routes all messages associated with a particular unit-of-order to the same member destination
    of the targeted distributed destination. A persistent store is used to save the state of which member destination a particular unit-of-order currently using. When a path
    service receives the first message for a particular unit-of-order bound for a distributed destination, it uses the load balancing heuristics to select which member destination
    will handle the unit and writes that information into the persistent store. Note that when a unit-of-order has no unconsumed messages pending, the path service entry is
    removed and future messages may be sent to other member destinations.

    If the path service is not configured, WebLogic uses a hash-based routing mechanism. The hash-based routing algorithm uses the unit-of-order name to determine to which
    member destination the unit-of-order is associated. This means that the routing decision is made in the client based on the number of configured member destinations without
    any considerations for the load balancing heuristics.

    An example set-up can be found here - http://middlewaremagic.com/weblogic/?p=6334 (in the 'example' section).
  • 3. Re: jms order of message delivery with high availability
    Tom B Expert
    Currently Being Moderated
    Rene's information is a bit of out-of-date for all customers at 10.3.4 or later, at least with respect to the caveats about UOO and Topic MDBs, where using the new MDB "one-copy-per" modes addresses the issue. (It looks like a cut-and-paste from old documentation?) I recommend consulting the MDB Programmer's guide.

    Tom
  • 4. Re: jms order of message delivery with high availability
    Tom B Expert
    Currently Being Moderated
    About ordering

    Since you have ordering requirements, yes, you very likely can make good use of unit-of-order, regardless of whether you use a distributed destination. There's a chapter on UOO in the JMS programmer's guide.

    About message recovery

    When a JMS server goes down, its messages will remain trapped until it's restarted (switching from a queue to a topic will not be suitable help with your use case). There are two basic options for automatically restarting a JMS server: "Whole Server Migration" and "Automatic Service Migration". The former restarts an entire WL Server either on the same machine or a different machine, and the latter restarts a JMS server on a different WL server in the same cluster. There's a white-paper on the latter here: http://www.oracle.com/technetwork/middleware/weblogic/messaging - "Automatic Service Migration (pdf)".

    About full coverage of a distributed queue

    A non-MDB "vanilla" consumer pins to a single distributed destination member. To ensure full coverage of consumers across a distributed destination the main options are:

    (A) simply use a WebLogic MDB (highly recommended)
    (B) run many consumers, and have them periodically close and reconnect
    (C) setup consumers directly on each member (JNDI name will be "jms-server-name@dist-dest-jndi-name")
    (D) use destination availability helper APIs to programmatically discover destination membership (advanced use case).

    About WebLogic JMS in General

    1 http://www.oracle.com/technetwork/middleware/weblogic/messaging

    2 See config best practices: http://download.oracle.com/docs/cd/E17904_01/web.1111/e13738/best_practice.htm#JMSAD455

    3 The book "Professional Oracle WebLogic Server" has a nice JMS chapter. It's a little out-of-date if you're on WebLogic 10.3.4 or later, particular with respect to distributed topics, but otherwise you'll probably find it to be pretty helpful. (For extensive information on topics consult both the MDB and the JMS programmer's guides.)

    HTH,

    Tom

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points