[ 
https://issues.apache.org/activemq/browse/AMQ-1792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46147#action_46147
 ] 

Gary Tully commented on AMQ-1792:
---------------------------------

I worked through the test case. What happens is that each of the consumers gets 
a shot at consuming all of the existing messages (5) in the queue. The recovery 
dispatch in Queue.addSubscription is responsible for that.
For the two consumers that do work, 1 message gets dispatched that fills the 
subscription (because of the prefetch value) and the onMessage blocks. Because 
of the transacted session, an on delivery ack results in the prefetch being 
exceeded by one and a second message is dispatched. This results in 4 of the 5 
messages locked/dispatched.
For the third, it consumes and generates an new message. the third consumer is 
thus not full and consumes what it produced. This continues for 5 seconds until 
one of the other two consumers becomes available and consumes what the third 
produces. This ends the third consumers run as all available messages have been 
dispatched.

To see a change in behavior, increase the Config.sMESSAGESTOSEND to 10. In this 
way, two iterations of consumer 1 and 2 will be needed to consume ~6 messages, 
leaving 4 for consumer three so it will continue past the first consumer 
commit. These remaining messages will get dispatched between the available 3 
consumers and consumer 3 will be able to continue.

I think things are working as expected here. Don't think it is critical.

> Consumer stops work when another consumer commits
> -------------------------------------------------
>
>                 Key: AMQ-1792
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1792
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.1.0
>         Environment: Win XP, Java 1.5
>            Reporter: Kevin
>            Assignee: Rob Davies
>            Priority: Blocker
>             Fix For: 5.3.0
>
>         Attachments: Situation.zip
>
>
> Hi *,
> 5 messages are put into a queue. 3 consumer are created, all with their own 
> transacted-sessions. They all implements MessageListener.
> 2 consumers recieve a message, wait 5 seconds and commit their messages. The 
> other consumer sends the recieved message back to the queue (no rollback!!!) 
> and commit. When one of the first consumer commits, the third consumer stops 
> working and doesn't recieve any messages.
> When you starts the attached Main-class (sets first the ip-address of your 
> broker in the config-class) you'll see some output:
> Consumer-1 work begins!
> Consumer-2 work begins!
> Consumer-3 cant work!
> Consumer-3 cant work!
> [..]
> Consumer-3 cant work!
> Consumer-3 cant work!
> Consumer-1 work ends!
> Consumer-1 work begins!
> Consumer-2 work ends!
> Consumer-2 work begins!
> Consumer-1 work ends!
> Consumer-1 work begins!
> Consumer-2 work ends!
> Consumer-1 work ends!
> "Consumer-3 cant work" means, that consumer-3 sends a message back to the 
> broker. "Consumer1-work begins" is the first code-line in the 
> onMessage-Method, "Consumer1-work ends" the last one.
> I also attached the configuration file of the broker, maybe I made something 
> wrong there.
> I hope this issue will not go unheeded like my other issue posted a week ago.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to