DMLC Design Question

[luddy.sg]

Hello,

I have a DMLC app that needs to process incoming messages in parallel based on a parameter in the message.
This parameter can range from [1..16]. Messages with the same parameter value must be processed serially.

So, my design has 16 FixedPoolExecutorServices, each with a single thread.

My DMLC is configured with ONE single thread that reads off the queue, unpacks the parameter and puts it on one of the 16 executor services based on the value of the parameter.

Each of these 16 threads may throw an exception and I want that exception propagated back to the onMessage so that the message can be rolled back and redelivered on MQ.

Is this the correct approach?

The reason I don't believe it is is because once the onMessage submits the callable, it returns immediately and submits another one. When it gets an exception, it cannot determine which message triggered the exception.

Thanks.

[Gary Russell]

Right, if you want exceptions to propagate back to the container and roll back, you must process the message on the container's thread.

You would need to use a separate DMLC for each, and give them an appropriate MessageSelector http://static.springsource.org/sprin...a.lang.String)

With one consumer per DMLC, the container will configure the single consumer with the selector so it will only get the messages it wants.

[oleg.zhurakousky]

Actually no. As you said DMLC will assume everything went well if MessageListener returns successfully and since you are delegating to a different thread it always is.
Here is what you can do. Look at his sample I did for the last year's Spring One https://github.com/olegz/s12gx.2011/...on/resequencer. The general requirement is very simple to yours as you can read from the readme file. BUt you may need to do a slight modification. In the SequenceProcessor class that I have there you may want to submit and get the java.util.concurrent.Future which you can interrogate later on in the submitting thread and determine if everything went fine and if not re-throw the exception which will force the rollback.

[oleg.zhurakousky]

Just to clarify, "Actually no" remark was addressing your original question and was not a reply to what Gary just posted above which is also another way of handling it.