Concurrency
Its been a while since my last post unfortunately. I've been pretty busy lately and I'm still trying to come to grips with blogging as this is my first attempt. Anyway, I have been doing some testing with Correlation in Java CAPS and I thought I'd put together a little tutorial on how to use it, but before I post that (I still have to write it up) I thought I'd put together a quick post on Concurrency.
Serial Mode Processing
In Java CAPS, the standard mode for processing messages from a queue is single threaded or Serial Mode processing. This means that only one message is processed at a time and awaiting messages are "queued" up.
This method of processing guarantees that messages will be processed in a particular order. It also simplifies the solution making it a little easier to debug.
The problem with this method of processing is that if a process is delayed, or is stopped, then all processing is stopped or delayed.
Replication
One method to get around the issue is to replicate processing components to create a form of parallel processing. For those with experience in 4.X of the former eGate product, this will sound familiar.
In the above example, 3 instances of the process have been created allowing up to 3 messages to be processed at once.
The disadvantage of this method of processing is that the order of messages can now NOT be guaranteed. Another problem is that the processes have to be replicated manually.
This method also uses more resources (Memory and CPU cycles) simply because its processing more at the same time.
I can now hear you thinking, "That's cool, but there surely must be a better way to do multi-threaded processing in Java CAPS, what if I want 5, 10 or more threads, this is too much work".
Well, there is :-)
Consumer Mode Processing
We actually don't recommend that you use the "Replication" method to do multiprocessing. Consumer Mode processing is the way to go.
Here, Java CAPS automatically spawns new threads as required to process messages. The user specifies the maximum number of threads they wish spawned (The default is 5) and the whole thing is taken care of during runtime.
Again, this has the disadvantage that message order cannot be guaranteed during runtime.
How to Use
Now lets discuss how to implement Consumer mode processing within Java CAPS.
On your connectivity map, double click the little box that lies between your queue and your service.
This will bring up a dialog box with the properties for that link. Then expand out the "JMS Client" node and select "Basic".
Select "Serial Mode" in "Concurrency", this will bring up a drop down box giving you the selection of which mode you with to run under.
Select "Connection Consumer Mode" for Consumer Mode processing.
Click the "Advanced" node on the tree view. The "Server Session Pool Size" determines the number of threads spawned for the subscribing process. As you can see, the default is 5.
Click "OK" to return to the connectivity map.
Save everything, re-build and deploy.
When To Use
Serial mode processing should be used whenever the message order is important. You may also wish to leave "Serial Mode" on for initial unit testing to make sure functionality is correct, then change to "Consumer Mode" when ready for system testing or during performance testing.
Consumer Mode should be used where message order is not important, and there are bottlenecks in the system.
Ultimately, every implementation is different, so I cannot give you exact guidelines on when to use which mode, but have a play, use your common sense and try a few things out.
A few Last Words
I hope you find the above quick tutorial helpful. I plan on doing a few more. One on Correlation, Message Re-delivery and Redirection Handling, Web Services and Error Handling.
When I get some time, I'd also like to play around with Sun's Open ESB that comes with Netbeans 6.
Well, that's it for today. Good luck with your Java CAPS implementations.
Posted at 10:46AM Nov 16, 2007 by Holger Paffrath in Sun | Comments[1]

We have a situation where we need in-order processing of messages from a single soure, but order-less processing from multiple sources.
We have JCAPS 6u1
When dealing across sources, we want (and must have) multi-processing. We envision using both multiple instances (server farm) and multi-threading.
In an SOA environment, we think multi-threading means making every service responsible for its being thread aware, and using temp response queues from getting back to the correct calling thread.
Any thoughts on that.
Posted by Bruce Laidlaw on August 27, 2009 at 01:04 AM EST #