Re: DefaultMessageListenerContainer and 5.1

[MichaelShaw <mi...@gmail.com>]

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.