From dev-return-16251-apmail-activemq-dev-archive=activemq.apache.org@activemq.apache.org Wed Aug 05 14:48:55 2009 Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 57229 invoked from network); 5 Aug 2009 14:48:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Aug 2009 14:48:54 -0000 Received: (qmail 70483 invoked by uid 500); 5 Aug 2009 14:49:02 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 70419 invoked by uid 500); 5 Aug 2009 14:49:01 -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 70409 invoked by uid 99); 5 Aug 2009 14:49:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 14:49:00 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Aug 2009 14:48:57 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 2E63E234C052 for ; Wed, 5 Aug 2009 07:48:36 -0700 (PDT) Message-ID: <871162903.1249483716188.JavaMail.jira@brutus> Date: Wed, 5 Aug 2009 07:48:36 -0700 (PDT) From: "Dejan Bosanac (JIRA)" To: dev@activemq.apache.org Subject: [jira] Resolved: (AMQ-1807) Activemq stops dispatching messages aborting transaction (STOMP) In-Reply-To: <134144959.1213783980283.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: ae95407df07c98740808b2ef9da0087c X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/activemq/browse/AMQ-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac resolved AMQ-1807. -------------------------------- Resolution: Fixed Fix Version/s: (was: 5.4.0) 5.3.0 Just looked at the test case again and it seems that this is working fine now (modified test case proves it). As for the redelivery policy, it is not implemented for Stomp. I created another issue for this: https://issues.apache.org/activemq/browse/AMQ-2345 > Activemq stops dispatching messages aborting transaction (STOMP) > ---------------------------------------------------------------- > > Key: AMQ-1807 > URL: https://issues.apache.org/activemq/browse/AMQ-1807 > Project: ActiveMQ > Issue Type: Bug > Components: Transport > Affects Versions: 5.1.0 > Environment: Linux, JDK 1.6_06b2 > Reporter: Celso Pinto > Assignee: Dejan Bosanac > Priority: Critical > Fix For: 5.3.0 > > Attachments: stomp_test.patch > > > As requested by Dejan Bosanac, I'm adding this ticket. I'm willing to help fix it, ie. I can get my hands dirty, but I must have some pointers on where to look because (unfortunately) I don't have much time to learn ActiveMQ's internals and architecture. > A copy of the email I sent to the users mailing-list: > ============================================= > I'm currently struggling to understand the reason behind that's causing the behaviour described in the subject: I'm connecting to activemq via stomp on a python app. Because I need to have the messages rolled back in case of some processing failure I'm wrapping the message processing in the following way: > message received -> start transaction -> ack message in transaction -> > process message -> if no exception commit tx, else rollback transaction > AFAIK, this is the only way of making message unacknowledgement possible with stomp. Also, this is a single client connection, ie. I'm using a > single client connection to create a message processing daemon, all messages are sent and received via this single connection to the MQ server. > Here's a telnet session that can be used to reproduce the problem (open jconsole and send 5 text messages to the queue): > % telnet localhost 61613 > Trying 127.0.0.1... > Connected to localhost. > Escape character is '^]'. > CONNECT > ^@ > CONNECTED > session:ID:starfish-53281-1213736462979-2:2 > SUBSCRIBE > destination: /queue/testq > ack: client > activemq.prefetchSize: 1 > ^@ > MESSAGE > message-id:ID:starfish-53281-1213736462979-3:3:1:1:1 > destination:/queue/testq > timestamp:1213736837743 > expires:0 > priority:0 > 1 > BEGIN > transaction: 1 > ^@ > ACK > message-id:ID:starfish-53281-1213736462979-3:3:1:1:1 > transaction: 1 > ^@ > MESSAGE > message-id:ID:starfish-53281-1213736462979-3:4:1:1:1 > destination:/queue/testq > timestamp:1213736840224 > expires:0 > priority:0 > 2 > MESSAGE > message-id:ID:starfish-53281-1213736462979-3:5:1:1:1 > destination:/queue/testq > timestamp:1213736842611 > expires:0 > priority:0 > 3 > ABORT > transaction: 1 > ^@ > BEGIN > transaction:2 > ^@ > ACK > message-id:ID:starfish-53281-1213736462979-3:4:1:1:1 > transaction:2 > ^@ > ABORT > transaction:2 > ^@ > ACK > message-id:ID:starfish-53281-1213736462979-3:5:1:1:1 > ^@ > I see a couple of issues here: > #1) even though I specified activemq.prefetchSize to 1 in the subscription command, the connector dispatches two messages in a row > #2) no more messages are dispatched after aborting the transaction/acknowledging the last received message. Even if the second message isn't wrapped in a transaction, message dispatch stops there. > To add to the confusion, if I don't use transactions _at all_, my client keeps getting messages, one by one, ie. no two messages are sent together, I only get a new message after ACK'ing the previous one. > I think I may be stepping into the realms of a buggy STOMP connector. Please tell me if I'm missing something obvious that fixes this issue > (hence making it a non-issue) or if indeed the STOMP connector has problems. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.