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
Subscribe to: Comments (Atom)