Multithreaded JMS application

Question

I am working on a multithreaded JMS receiver and publisher code. XML message is received from a Queue, stored procedures(takes 70 sec to execute) are called and response is send to Topic within 90 sec. I need to handle a condition when broker is down. i.e. a condition in which messages are received from Queue and are being processed in java, in the mean time both Queue and Topic will be down. Then how to handle those messages which are not on queue and not send to topic but are in java memory? Different options available:

1.To use CLIENT_ACKNOWLEDGE 2.To separate publisher code from receiver code. 3.To have error utility which will take messages from log and process them and send to Topic(least preferred)

Please suggest me the right option

Answer 1

Use a transacted session. Consume the message and send the response under a single unit of work and explicitly call COMMIT after sending the response. Then if the broker dies while the transaction is outstanding the input message will be rolled back. If you include the DB update in a two-phase coordinated transaction then it too can be rolled back of the broker goes down. This requires the consumer and responder to be within the same thread because JMS scopes sessions per thread, but you can have several threads running sessions in parallel.

Be aware that keeping many transactions open for 90 seconds might require some tuning at the broker side.

Answer 2

One solution is to use db for intermediate stored procedure. So the steps would be:

1. Consume Message from Queue and store into db and use Client_Acknowledge.
2. Run stored procedures on the consumed message.
3. Once the procedure is over, send message from db to the topic.
4. Delete message once acknowledgement is recieved.

If queue and topic goes down in between, you just need to send message again when acknowledgement is not recieved from topic.

Well I am not sure whether this is the best alternative and want to see how community responds on this question.