[jira] [Comment Edited] (AMQ-3485) Transacted Session returns invalid MessageConsumer after the first MessageConsumer for the same destiantion. Bug introduced in 5.5.0 - working ok in 4.1.2

["Dejan Bosanac (JIRA)" <ji...@apache.org>]

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

Dejan Bosanac edited comment on AMQ-3485 at 10/23/12 12:34 PM:
---------------------------------------------------------------

So we investigated this in more details. The problem was introduced with a fix for [AMQ-2034], when we started postponing the closing of the actual consumer until transaction ends (either commit or rollback). This leads us to the problem where the messages that were already prefetched by the consumer are stuck on that consumer until the end of the transaction.

The easiest workaround for this is to turn of prefetching, with something like

{code}Destination dest = session.createQueue("TEST?consumer.prefetchSize=0");{code}

And frankly turning of the prefetch in use cases where you want to have multiple consumers coming and going inside the single transaction make the only sense, as every other approach will mess the order of messages.

To support closing consumers with prefetched messages inside the transaction we'd need to refactor the whole thing. Ideally the consumer would close immediately and on transaction end, broker would know how to redeliver unconsumed messages.

Let me know if this workaround works for you.
                
      was (Author: dejanb):
    So we investigated this in more details. The problem was introduced with a fix for [AMQ-2034], when we started postponing the closing of the actual consumer until transaction ends (either commit or rollback). This leads us to the problem where the messages that were already prefetched by the consumer be stuck on that consumer until the end of the transaction.

The easiest workaround for this is to turn of prefetching, with something like

{code}Destination dest = session.createQueue("TEST?consumer.prefetchSize=0");{code}

And frankly turning of the prefetch in use cases where you want to have multiple consumers coming and going inside the single transaction make the only sense, as every other approach will mess the order of messages.

To support closing consumers with prefetched messages inside the transaction we'd need to refactor the whole thing. Ideally the consumer would close immediately and on transaction end, broker would know how to redeliver unconsumed messages.

Let me know if this workaround works for you.
                  
> Transacted Session returns invalid MessageConsumer after the first MessageConsumer for the same destiantion. Bug introduced in 5.5.0 - working ok in 4.1.2
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3485
>                 URL: https://issues.apache.org/jira/browse/AMQ-3485
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.5.0
>            Reporter: Pablo La Greca
>            Assignee: Dejan Bosanac
>         Attachments: activemq-issue-test-case.zip
>
>
> When I have a transacted Session, as it is single threaded I can't create two MessageConsumer to the same Destination. But if I create a MessageConsumer to a Destination and then I close it, then I should be able to create a new MessageConsumer to the same Destination. This is working fine in active mq 4.1.2 but it doesn't work in 5.5.0. It allows to create a second MessageConsumer but that seconde MessageConsumer always returns null when the queue has messages.
> i.e:
> Session session = .... //transacted session
> Destination dest = .... 
> MessageConsumer mc = session.createMessageConsumer(dest);
> Message message = mc.receive(); // message received ok
> mc.close();
> mc = session.createMessageConsumer(dest);
> Message message = mc.receive(); // message is null
> Thanks, Pablo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira