Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A515DC8C for ; Tue, 23 Oct 2012 12:35:14 +0000 (UTC) Received: (qmail 50691 invoked by uid 500); 23 Oct 2012 12:35:13 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 50620 invoked by uid 500); 23 Oct 2012 12:35:12 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 50581 invoked by uid 99); 23 Oct 2012 12:35:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Oct 2012 12:35:12 +0000 Date: Tue, 23 Oct 2012 12:35:12 +0000 (UTC) From: "Dejan Bosanac (JIRA)" To: dev@activemq.apache.org Message-ID: <490959872.15611.1350995712125.JavaMail.jiratomcat@arcas> In-Reply-To: <931206033.23261.1315363149939.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (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 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/AMQ-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482288#comment-13482288 ] Dejan Bosanac commented on AMQ-3485: ------------------------------------ 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