I would like to know if anyone has a solution for the following - A JMS sender sends a message. JMS receiver 1 picks it up, but freezes or fails to send message acknowledgement in the required amount of time. Require a way to determine that receiver 1 is frozen or slow and enable pickup and processing of the message by receiver 2. I know that if receiver 1 crashes, the message is available for receiver 2 to pick up. What I would like to know is if there is any way for receiver 2 to pick up the message if receiver 1 happens to take a time longer than a given duration to process the message (due to some other issue with receiver 1).
First off, messaging is inherently asynchronous, meaning you get ZERO guarantee when a message will be read and acted on. That said, you could set up your system to send messages to two queues (either explicitly in the message sender or using some server-level queue management), with receiver 1 on queue 1 and receiver 2 on queue 2. If 'somehow' receiver 2 detects receiver 1 has crashed he can then act on the message.
Keep in mind, redundancy is one thing, but if you are writing code that expects one receiver to fail, chances are your time would be better spent making sure it doesn't.
Do you mean if receiver 1 picks up the message, but takes more than enough to process due to any failure or computation freeze on his side. Receivers 2 comes and pick up the message to process?
What about using a demand store in your application server side, where you store the status of every single message to the point they're computed 100%, and remove the status afterward. Then, you can have the option to inquiry anything over there. Any pending message, which is not processed yet.
(+) Simple to implement, very handy in different situations, easy to learn about any failure in your system and route to another receiver.
(-) If you have cluster of application server, you need to have either distributed instances of your demand store. This makes the tracking very complicated.