Question

I had to create a message Listener (for some jms topic) in a stand alone application.
Since each message I receive has to do some processing.

This behavior delaying my whole performance.

So I decided to create kind of POOL to my message listeners. (as in MDB’S in ejb’s).

I started using Executor class(Java) this way:

import java.util.concurrent.Executor;
import java.util.concurrent.Executors; 

    private Executor threadPool = Executors.newCachedThreadPool();
    @Override
    public void onMessage(final Message msg)
    {
        Runnable t = new Runnable()
        {
            public void run()
            {
                execute(msg);
                log.trace(received messge");
            }
        };
        threadPool.execute(t);
    }

public void execute(Message msg)
{
   // do some long running process)
}

In this way I make sure my application wont stuck from one message to another while processing by creating separate Thread for each execution.

I would like to have your suggestions by your experience..
is that kind if implementation might cause any future problems? on what should I pay attention(I know concurrency is an issue)?

Answer 1

This is JMS, why don’t you just pool MDBs? You can then avoid having a separate thread pool. Also unprocessed items aren’t lost if you shut down the application in the meantime.

Make sure you understand the difference between cached and fixed thread pool (see: Java newCachedThreadPool() versus newFixedThreadPool). It may or may not be what you want. I typically go for fixed thread pool as I want to know the maximum number of open threads in advance.

One small thing: put logging before you process the message (as well), so that you can easily tell for how long it was processed. If you used fixed pool, knowing how long it was queued is also valuable.