I am working on a scenario which uses Asynchronous consumer(Spring DefaultMessageListenerContainer) with transactions and durable subscription enabled. In the message listener class I am throwing an exception whenever I receive any message, which forces SonicMQ to redeliver the message again and again. So far everything is fine. But my requirement is to configure some interval between each redelivery. Also I need to set some max delivery count for the redelivery. If it exceeds the max delivery count, I want to move that message to the DMQ.
I greatly appreciate any pointers.
Delayed Delivery -- there is no setting for this. However, if you throw the exception, then it will be put back in the delivery channel as the next message, so you could just wait before reading again. (Another thing to look at is "AckAndForward" -- that is, send the message to another queue, where you'd read/look at date/ and then resend back to the first queue.
Max Delivery Count -- In the recent SonicMQ, you can check the JMSXDeliveryCount property header (I think it came in in 7.6.something) and base things on that. However, you can't send messages to the DMQ yourself. You'd have to have your own sender to do this.
Hi William
I'm looking for a function like this too. A lot of our messaging is asynchronous and we want the ESB to manage retrying, with delays between retries, and timeouts based on elapsed times and number fo retries. I see the principle of using Java Service Types to manage the process.
I guess the technique is to use a Thread.sleep, but what happens when:
- the container is stopped
- the server stops abruptly (power failure etc)
I'm working with Sonic ESB 8.0.1.
Hi Prasad
I'd be interested to hear what approach you came up with.
The approach I'm considering to keep count is to add a "Retry" Message Part to record things like:
- Next Retry time
- Maximum Retry timeout time
- Number of Retries
- Maximum number of retries.
The JST would manage the Retry message part
- create it if it isn't there
- look after the incrementing
Any better/alternative ideas would be most welcome.
Regards
Steve