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/
