[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    [jira] Assigned: (AMQ-1807) Activemq stops dispatching messages
From:       "Dejan Bosanac (JIRA)" <jira () apache ! org>
Date:       2008-10-29 12:53:52
Message-ID: 317669173.1225284832661.JavaMail.jira () brutus
[Download RAW message or body]


     [ https://issues.apache.org/activemq/browse/AMQ-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Dejan Bosanac reassigned AMQ-1807:
----------------------------------

    Assignee: Dejan Bosanac

> 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.


[prev in list] [next in list] [prev in thread] [next in thread]