I am experiencing a similar issue.
When a consumer of a queue fails to acknowledge() a message, getting a
queuebrowser instance and calling
getEnumeration() is causing all the messages that are unacknowledged to be
redelivered.
This is a distinct change in behavior from 4.1.1 to 5.1.0. In 4.1.1, the
message was not automatically redelivered to the consumer.
Intentional?
rajdavies wrote:
>
>
> 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/
>
>
>
>
>
--
View this message in context:
http://www.nabble.com/DefaultMessageListenerContainer-and-5.1-tp17135019p19170785.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
