From users-return-14614-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Tue Jun 17 21:29:37 2008 Return-Path: Delivered-To: apmail-activemq-users-archive@www.apache.org Received: (qmail 19004 invoked from network); 17 Jun 2008 21:29:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Jun 2008 21:29:35 -0000 Received: (qmail 8336 invoked by uid 500); 17 Jun 2008 21:29:36 -0000 Delivered-To: apmail-activemq-users-archive@activemq.apache.org Received: (qmail 8315 invoked by uid 500); 17 Jun 2008 21:29:36 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 8304 invoked by uid 99); 17 Jun 2008 21:29:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jun 2008 14:29:36 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [66.249.92.175] (HELO ug-out-1314.google.com) (66.249.92.175) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 Jun 2008 21:28:46 +0000 Received: by ug-out-1314.google.com with SMTP id u2so682619uge.5 for ; Tue, 17 Jun 2008 14:29:02 -0700 (PDT) Received: by 10.210.126.5 with SMTP id y5mr8257688ebc.56.1213738142370; Tue, 17 Jun 2008 14:29:02 -0700 (PDT) Received: from ?192.168.1.10? ( [89.152.220.166]) by mx.google.com with ESMTPS id 34sm3585711ugh.8.2008.06.17.14.29.00 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Jun 2008 14:29:01 -0700 (PDT) Subject: activemq stops dispatching messages aborting transaction (STOMP) From: Celso Pinto To: users@activemq.apache.org Content-Type: text/plain Date: Tue, 17 Jun 2008 22:28:58 +0100 Message-Id: <1213738138.15850.18.camel@starfish> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi all, 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. TIA, Celso