On 8 May 2008, at 22:02, BlueFox wrote:
I just did some more checking, turns out it is the QueueBrowser that
is
causing the duplicate message problem. I have a QueueBrowser that
uses the
following code to periodically verify the queue size and perform
verification after queue size is zero.
private static class JMSBrowser implements SessionCallback {
@Override
public Object doInJms(javax.jms.Session session) throws
JMSException {
QueueSession queueSession = (QueueSession) session;
Queue queue = queueSession.createQueue("test.queue");
try {
System.out.println("Monitoring queue...");
boolean hasMoreItem = true;
while (hasMoreItem) {
QueueBrowser browser =
queueSession.createBrowser(queue);
hasMoreItem =
browser.getEnumeration().hasMoreElements();
browser.close();
System.out.println("Waiting for the queue to
clear up...");
// wait for 1s until checking
Thread.sleep(1000);
}
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("Queue cleared, proceed with
verification");
queueSession.close();
return null;
}
}
Before upgrading to 5.1, this queue browser works correctly and only
terminates when the queue is empty. (Works in both 5.0 and 4.1.1)
However,
with new 5.1 binary I get 2 error behavior:
1. This queue monitor will terminate even if there is still data in
the
queue
2. Duplicate messages are delivered to consumer if monitor queue is
used.
BlueFox wrote:
Hi I just upgraded to 5.1 and there seems to be a very weird behavior
regarding the message redelivery.
Before upgrade to 5.1, I had the Spring 2.5.3 and 5.0 running fine
with
the following setup.
1. I have a single producer sending and recording 100 persistent
messages
to a queue.
2. maximumRedeliveries for message is set to -1
3. I use Spring DefaultMessageListenerContainer (sessionTransacted
= true)
to create a single exclusive consumer on the queue, and
session.rollback(); is randomly called to simulate transaction
failure.
4. When the queue size reaches 0, I verify that all 100 messages are
correctly received and in order.
Everything was working fine in 5.0, but in 5.1, I noticed that
duplicate
messages were received. However, if I change the cacheLevelName on
the
DefaultMessageListenerContainer from the default CACHE_CONSUMER to
anything else, the test then runs fine. However, since I also have
exponential backoff implemented for redelivery, changing the cache
level
will render the policy useless since the connection & session are
recreated by the container.
Thoughts?
--
View this message in context:
http://www.nabble.com/DefaultMessageListenerContainer-and-5.1-tp17135019s2354p17136302.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
could you raise a jira for this issue so we can track it ?
cheers,
Rob
http://open.iona.com/ -Enterprise Open Integration
http://rajdavies.blogspot.com/
