The easiest way is to have a Proxy service listening from the error queue and set the JMSDeliveryTime to the absolute time of two hours ahead, putting back in the originating queue.
You have to be careful to avoid some messages being in the loop forever....
Another way is to set for the error queue Queue -> Overrides -> "Time-to-Deliver Override". This is the delay in millis.
Then have a proxy service consuming from the error queue and moving the message back to the normal queue.
By doing that, the proxy will always be listening the queue, however it will not pickup the message until the delivery time is reached.
Thanks for the quick reply of my query . When I was going through the definition of time to delivery parameter , I found the following definition
"The default delay, either in milliseconds or as a schedule, between when a message is produced and when it is made visible on its target destination, regardless of the delivery time specified by the producer and/or connection factory."
I can set time in milli seconds , that is ok and fine but can you please let me know how to set this schedule in this parameter ?
If you take the approach of setting the override in the Error queue, you just specify the delay in milliseconds. The absolute time will be automatically calculated. There is no scheduling involved.
Your other proxy service will be listening to the queue. Whenever the delay elapses, then the message will be "visible" to the proxy service and the message will be consumed.
We also have one parameter Delivery Mode Override under overrides tab .
If I donot set this parameter as "PERSISTENT" will my message be lost without sending it back to error queue ?
This is currently happening in my scenario . I have not set this parameter and my message are lost without sending to error queue .
Please advice and let me know the use of this parameter(Delivery Mode Override) when I have already set the Delivery Failure tab parameters viz. Expiration policy -->Redirect and Error Destination--- > My error queue ?
No, the message should go to the error queue. If it's not persistent, it could be lost if the server is restarted, for example.
Were the messages being sent to the error queue before in case of a failure? Note that for that to happen, there are a couple of things to keep in mind, such as do not use the reply action in the pipeline and other QOS settings.
It's correct to Raise Error.
Make sure that "Redelivery Limit" is not set to -1. Set to zero, just to make it easier to test, then you can change it later to meet your requirements.
An important question, so I can help you: Was the message being moved to the error queue before you make the config changes? What changes exactly did you make?
What is the usage in your pipeline? You consume from one queue and then do what?
16 is the default number of consumers if you don't specify a work manager. What you described is not correct. Only One consumer gets a message, and if it fails it rollback. If there is unlimited number of retries, then the message will go back to the queue, the proxy service will try again and if it fails this will go on forever.
If you answer my questions in my previous message, it will make it easier to understand where we are.
Have you already developed the other proxy service to put the message back in the normal queue?
I have two proxy services . One proxy service is receiving message from a queue and sending it to target system .In case it fails I have second proxy service which is polling error queue and sending message back to normal queue via a business service (In biz service I have configured normal queue URL).
But currently when my target system is not available the messages are going to normal queue's pending message list . They are no longer going to error queue even after waiting for a long time .
The time I configured under delivery failure tab is as under :
As per configurations the message should go to error queue after 3*10000 =30 seconds . But even after waiting for 10 minutes the messages were there in normal queue's pending list . They are not moving to error queue . Hence the error proxy cannot work and put the message back to normal queue .
Please look into it and help why after 30 seconds messages dont move to error queue .