java.util.concurrent Package

Currently we're working on a standalone java engine to process billing for customers.
The EA has decided to use Command pattern and a command factory which upon receiving messages is supposed to create a new command
and submit it to an ExecutorService object to queue it, so it would be run by one of the worker threads in the pool.

Each command returns a set of command results which is in a form of Futuretask object and can lead to creating another command which is supposed
to be submitted to ExecutorService to run.

We need to process around 8 messages per second based on SLA, which indicates performance is critical.

I have not worked with concurrent package before. In the opinion of those who know the package well, what is best practice here in selecting Executor and command result queue?
What we currently have is a module A firing messages through an interface to module B, which is a singleton object declared through Spring bean factory. This module B uses a command
factory to decide which command to generate and then submits it to ExecutorService. We use a bounded queue to avoid memory problems, and this leads to commands getting rejected if the
queue fills up. We also have another thread which runs independent of module B and listens to a cuncurrent queue to handle command results being delivered. Here's the pseudo code:

module B
------------
<Start engine>
<Initialize queues , executor object and command result listening thread>
<pass the received message to command factory and determine what command to generate>
Loop indefinitely // this will take care of rejected tasks
<Submit the command to Executor Service object and get the Futuretask object in return>
<Add the future task object to a concurrent queue>
If submitted then break from loop;
end loop;
<this thread ends>

Thread listening to command result queue
------------------------------------------------
loop forever
<listen to command result queue>
<process result>
<if a new command has to be generated submit it to Executor service>
end loop

We have not yet tested this with high volume messages coming in from module A to module B.
Is there any insight on what issues we might be getting into by using the above design?

I believe the concurrent queue for the command result is a part of a threadpool (executor), if not then it should be.

Second thing that i would recommend is to not to go in an infinite loop when a task is rejected. This will complicate matters when the load is too high, you will get into a CPU bound thread that can worsen the situation as it may so happen that the main worker threads do not get enough CPU and hence result in more tasks getting rejected.
If the server is too busy, then mostly people return the same message to the client. If the messages are critical and can not be dropped, then you may think of persistent queues so that you can overflow to disk when the load is high and read from disk when load comes down.

We need to process around 8 messages per second based on SLA, which indicates performance is critical.

Unless you are doing a lot of processing per task, 8 mps is not a tough performance requirement at all.

Nitesh Kant wrote:I believe the concurrent queue for the command result is a part of a threadpool (executor), if not then it should be.

Second thing that i would recommend is to not to go in an infinite loop when a task is rejected. This will complicate matters when the load is too high, you will get into a CPU bound thread that can worsen the situation as it may so happen that the main worker threads do not get enough CPU and hence result in more tasks getting rejected.
If the server is too busy, then mostly people return the same message to the client. If the messages are critical and can not be dropped, then you may think of persistent queues so that you can overflow to disk when the load is high and read from disk when load comes down.

We need to process around 8 messages per second based on SLA, which indicates performance is critical.

Unless you are doing a lot of processing per task, 8 mps is not a tough performance requirement at all.

Thanks.
The above mentioned SLA is the minimum. The commands would have receivers which might make several calls to DBMS, most of them at least once. So in this context, I'll be cautious about 8 mps being an easy performer and we might end up with 100s of commands queued up waiting to be picked up by any available worker thread. 8 mps is 500 per minute, which says around 500 DBMS calls per minute or less.

As for keeping the command result a part of threadpool, it makes sense but then when you submit a command to ExecutorService as:

Future<T> commandResult = ExecutorService.submit(MyCommand);

, do you listen to the commandResult queue in the same thread? or do you listen to the commandResult queue in a different thread?

George Titan wrote: do you listen to the commandResult queue in the same thread? or do you listen to the commandResult queue in a different thread?

What i meant is that result processing must be in *a* threadpool rather than having one thread polling a queue.
Whether this is the same threadpool or different depends on your requirements. For instance, if i want to control the amount of threads for command and command result processing in a mutually exclusive way then i will have different threadpools.