Wednesday, July 25, 2012

Understanding the "singleton" property with WebLogic JMS topics

There are several reasons why WebLogic Server sucks, and one of them is this whole clustered JMS mess thing that continues to confuse everybody.

In this post, I will attempt to describe the behavior of the "singleton" property as well as the forwarding policies within JMS topics.


1. Create SOA Composite

As depicted in the screenshot below, I have a very simple composite that consists of a Mediator service and a BPEL project.

The Mediator service accepts a requests, and dumps it into a WebLogic JMS Topic.

The BPEL process consumes the message from the JMS Topic.



2. Test with and without the "singleton" property

In composite.xml, simply adding the singleton property as shown below in the JMS JCA Adapter binding is all that is needed. I will test with and without this property.



3. Create a Uniform Distributed Topic

As shown below, I created a Uniform Distributed Topic called "AhmedTopic" which is targeted to 2 JMS Servers.



4. Set Forwarding Policy in Topic

Initially, we will set the Forwarding Policy to "Replicated" but will test it with "Partitioned" as well later on.



Test #1 / Forwarding Policy Replicated / No Singleton

This resulted in 4 instances.
Basically, this is what happens:
  1. Mediator produces a single message
  2. Message is replicated across both JMS Servers on both nodes
  3. Since the code physically resides on 2 SOA servers, each SOA server will create an instance, consuming the message from each of the JMS Servers, resulting in 4 instances and 4 messages consumed total


Test #2 / Forwarding Policy Replicated / Singleton

This resulted in 2 instances.
Basically, this is what happens:
  1. Mediator produces a single message
  2. Message is replicated across both JMS Servers on both nodes
  3. Though the code physically resides on 2 SOA servers, the code on only one of the servers will consume the message, yet it still consumes it off of both JMS Servers, resulting in 2 instances and 2 messages consumed total


Test #3 / Forwarding Policy Partitioned / No Singleton

This resulted in 2 instances.
Basically, this is what happens:
  1. Mediator produces a single message
  2. Message resides on only a single JMS Server
  3. Since the code physically resides on 2 SOA servers, each SOA server will create an instance, finding and consuming the message from the JMS Server which has the message, resulting in 2 instances and 2 messages consumed total


Test #4 / Forwarding Policy Partitioned / Singleton

This resulted in 1 instance, which is the behavior that I want!
Basically, this is what happens:
  1. Mediator produces a single message
  2. Message resides on only a single JMS Server
  3. Though the code physically resides on 2 SOA servers, only one of the JMS Servers will have the message, and the singleton property will enforce only a single instance consumption as shown, resulting in 1 instance and 1 message consumed total


References:
  • Singleton (Active/Passive) Inbound Endpoint Lifecycle Support Within Adapters
http://docs.oracle.com/cd/E23943_01/integration.1111/e10231/life_cycle.htm#BABDAFBH
Ahmed Aboulnaga

5 comments:

REamon said...

Thanks for exploring this topic in more detail.

Alas, our experience differs from what is described here. The config we have matches what you described in test #3. Only one instance on one of the nodes created. Different messages may be processed on different nodes, but each message is processed only once. The "singleton" property appears to have no impact at all. (11.1.1.4)

And our root problem remains--how to serialize the processing of the messages on topic by a particular durable subscriber. Our search continues....

Ahmed Aboulnaga said...

Seems that the "singleton" property was introduced with 11.1.1.2, oo it's strange what you're experiencing.

http://www.oracle.com/technetwork/middleware/soasuite/soa-11gr1-ps1-new-features-096000.html

As for the requirement of having to process message in a strict sequence (pretty much FIFO), my recommendation is to handle this programmatically. We've done this successfully in a past project.

kiran krish said...

where to specify the Forwarding policy on weblogic server

REamon said...

Ahmed, can you try a variation for test #3? Perhaps it is already configured this way, but I'd like to see if this accounts for the difference in behaviors: define your topic CF with a client ID, shareable and unrestricted. I think this may result in each message being delivered just once to the "application".

kevin smith said...

Great Post! It's very nice to read this info from someone that actually knows what they are talking about.
homeowners association management