Asynchronous message aknowledgement problem

Question

Hi,
I am trying to set up a client/server app with a jms server acting as the com link. My client makes requests (async) to the server. It publishes a msg to the request queue of the jms server. The server subscribes to the request queue, processes the request and then publishes the answer to the processed queue of the jms server. The client is then notified by the jms processed queue.
The problem:
I now wish to multithread the server so that it deals with many request simultaneously. It subscribes to the request queue, and start processing. Because the requests are not uniform, some take more time to complete. If the server aknowledges an older request message then all msg up to the most recent are aknowleged. If at this point my server was to crash I wouldn't be able to recuperate the unprocessed request to which the corresponding messages have already been aknowledge.
I would like to have only the processed messages aknowledged and hence if the server crashes the server can resubscribe to pending requests.
Anyone see some neat trick round this problem?
thanks
av

Answer 1

thanks for the note, however this isn't really what I
am looking for. oh, boy, yes, it is what you are looking for:)
It is my understanding that using
mdbs will mean synchronous message consumption and
acknowledgment. it is sorta right, but mdbs can do concurrent work.
In which case this will create a
bottle neck as some messages need more time to process
than others.
nope. for example, you have two requests coming in, the first one, reqHour, would take an hour to finish, the second, reqSecond, takes only one second. when reqHour comes in, an instance of the mdb starts working on it. when the second one, reqSecond, comes in, it does not have to wait for an hour, rather, another instance of the mdb starts working on it right away (this is called concurrent processing, like a multi threaded). of course the second request will be finished first, the result will be put in the processed queue prior to the first lenghty one. if there are more requests come in, more instances of the mdb will be created to work on them.
I am looking for an async message
concumption/aknowlegement which does not act on all
messages at once. Not sure it is possible.
as above.
Myabe one way round this would be to create onthefly
queues for a given Connection where each queue is used
for only 1 message (or with a pool of queues), this
way message consumption does not affect the other
queues. However, can a subscriber find out about all
available queues? Maybe the solution is to follow a
fixed pattern of queue names..... not sure, I'll have
to think more closely about this one, but maybe this
could be a possible solution.
obviously, this is not a good way to go.
Anyone out there wants to expand on the above?urh? hope so.