1

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)?

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
rayman
  • 20,786
  • 45
  • 148
  • 246

1 Answers1

3

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.

Community
  • 1
  • 1
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • When you saying 'why dont u pool MDB'S' what do you mean? thats what i am trying to implement. The problem with fixed pool is that If I dont have free resources the whole execution will be stuck till ill get a free instance. this is something I cant allowed. my listener must be available all time. – rayman Oct 28 '12 at 14:19
  • @rayman: typically when you register MDB in an application server (or Spring for that matter) you can configure how many MDBs you want to process messages. 10 MDBs means up to 10 messages can be consumed concurrently, the rest is queued. But seems like you don't want fixed pool (which conceptually MDBs represent). However are you sure your system is capable of handling arbitrary number of messages? If you receive 1K messages at the same time, do you think 1K threads will all process equally fast? Well, it's technically possible, but... – Tomasz Nurkiewicz Oct 28 '12 at 14:27