Queueing a message in JMS, for delayed processing

Question

I have a piece of middleware that sits between two JMS queues. From one it reads, processes some data into the database, and writes to the other.

Here is a small diagram to depict the design:

With that in mind, I have some interesting logic that I would like to integrate into the service.

• Scenario 1: Say the middleware service receives a message from Queue 1, and hits the database to store portions of that message. If all goes well, it constructs a new message with some data, and writes it to Queue 2.

• Scenario 2: Say that the database complains about something, when the service attempts to perform some logic after getting a message from Queue 1.In this case, instead of writing a message to Queue 2, I would re-try to perform the database functionality in incremental timeouts. ie Try again in 5 sec., then 30 sec, then 1 minute if still down. The catch of course, is to be able to read other messages independently of this re-try. ie Re-try to process this one request, while listening for other requests.

With that in mind, what is both the correct and most modern way to construct a future proof solution?

After reading some posts on the net, it seems that I have several options.

• One, I could spin off a new thread once a new message is received, so that I can both perform the "re-try" functionality and listen to new requests.
• Two, I could possibly send the message back to the Queue, with a delay. ie If the process failed to execute in the db, write the message to the JMS queue by adding some amount of delay to it.

I am more fond of the first solution, however, I wanted to get the opinion of the community if there is a newer/better way to solve for this functionality in java 7. Is there something built into JMS to support this sort of "send message back for reprocessing at a specific time"?

Answer 1

JMS 2.0 specification describes the concept of delayed delivery of messages. See "What's new" section of https://java.net/projects/jms-spec/pages/JMS20FinalReleaseMany JMS providers have implemented the delayed delivery feature.

But I wonder how the delayed delivery will help your scenario. Since the database writes have issues, subsequent messages processing and attempt to write to database might end up in same situation. I guess it might be better to sort out issues with database updates and then pickup messages from queue.