[
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
