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:
Test #2 / Forwarding Policy Replicated / Singleton
This resulted in 2 instances.
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:- Mediator produces a single message
- Message is replicated across both JMS Servers on both nodes
- 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:- Mediator produces a single message
- Message is replicated across both JMS Servers on both nodes
- 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:- Mediator produces a single message
- Message resides on only a single JMS Server
- 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:- Mediator produces a single message
- Message resides on only a single JMS Server
- 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
- Uniform Distributed Topic: Configuration: General
http://docs.oracle.com/cd/E15586_01/apirefs.1111/e13952/pagehelp/JMSjmsuniformdestinationsjmstopicconfiggeneraltitle.html
- Using Replicated Distributed Topics
http://docs.oracle.com/cd/E23943_01/web.1111/e13727/dds.htm#BABEAGDF
- Using Partitioned Distributed Topics
http://docs.oracle.com/cd/E23943_01/web.1111/e13727/dds.htm#autoId16
- Tuning Topics
http://docs.oracle.com/cd/E23943_01/web.1111/e13814/jmstuning.htm#PERFM294
Applicable Versions:
- Oracle WebLogic Server 11g (11.1.1.5)
5 comments:
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....
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.
where to specify the Forwarding policy on weblogic server
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".
Great Post!!!!
Post a Comment