I meant the local queue internal to the consumer. I'm sorry, i guess I should be more careful about the terminology I use.
I've attached the ActiveMQMessageConsumer.java file that I changed. Look at the rollback method. Essentially what it did was (and correct me if i'm wrong here): 1. Calculate the redelivery delay 2. Schedule a task to start the consumer after that delay 3. Put all the delivered messages back on the list of unconsummed messages. 4. Tell the session to redispatch the messages. The problem is that there is nothing that tells the consumer that it shouldn't consume messages when they are available and step 4 makes the failed messages available. So, they are consumed again immediately after the call to rollback. Presumably the task scheduled in step 2 executes after the delay, but the messages have already been redelivered by this point. Does it make sense? Is it correct? Thanks again for your help with this James. -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 02, 2006 10:25 AM To: [email protected] Subject: Re: A few redelivery questions On 5/2/06, Litton, Tom - CEPM <[EMAIL PROTECTED]> wrote: > Thanks for the quick replies James. > > I have one more problem with the redelivery. > > Durring the rollback, the consumer registeres a task to start itself after a > certain delay. The messages are then put back on the queue for redelivery. > The problem is the consumer is never stopped. The result is that their is no > delay. The messages get processed immediantly after they are requeued. > > I changed the code to stop the consumer before the messages are requeued. Is > their a better solution? This solution will have problems if the consumer is > (permenantly) stopped during the delay, because it will just restart again > afterwards. I'm slightly confused. When messages are redelivered on a rollback, we tend to redeliver the messages inside the JMS client to the same consumer (after a timeout) to preserve ordering of messages on a queue (as soon as you send a message back to the broker to be re-dispatched you've broken ordering on the queue). So there should be a time delay when the message is redelivered to the same consumer. Its only if that consumer dies that it is redelivered to another consumer by the broker redelivering the message to a different consumer. So under normal redelivery processing consumers should not be stopped/started, nor should messages usually be placed 'back on the queue' -- James ------- http://radio.weblogs.com/0112098/ ---------------------------------------------------------------------- The information contained in this transmission is intended only for the personal and confidential use of the designated recipients named herein. If the reader of this transmission is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this transmission in error, and that any review, dissemination, distribution, or copying of this transmission is strictly prohibited. If you have received this communication in error, please notify the sender and return and delete the original transmission immediately. Thank you.
