Issue Details (XML | Word | Printable)

Key: AMQ-1807
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Dejan Bosanac
Reporter: Celso Pinto
Votes: 3
Watchers: 6
Operations

If you were logged in you would be able to see more operations.
ActiveMQ

Activemq stops dispatching messages aborting transaction (STOMP)

Created: 18/Jun/08 03:12 AM   Updated: 19/Aug/09 04:37 AM
Return to search
Component/s: Transport
Affects Version/s: 5.1.0
Fix Version/s: 5.3.0

Time Tracking:
Not Specified

File Attachments:
  Size
Text File Licensed for inclusion in ASF works stomp_test.patch 2008-06-30 05:00 PM Celso Pinto 3 kB
Environment: Linux, JDK 1.6_06b2


 Description  « Hide
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.



 All   Comments   Work Log   Change History   Subversion Commits   FishEye   Crucible      Sort Order: Ascending order - Click to sort in descending order
Celso Pinto made changes - 30/Jun/08 05:00 PM
Field Original Value New Value
Attachment stomp_test.patch [ 16651 ]
Rob Davies made changes - 10/Sep/08 05:13 AM
Fix Version/s 5.3.0 [ 11914 ]
Dejan Bosanac made changes - 29/Oct/08 05:53 AM
Assignee Dejan Bosanac [ dejanb ]
Dejan Bosanac made changes - 16/Dec/08 03:03 AM
Status Open [ 1 ] In Progress [ 3 ]
Dejan Bosanac made changes - 29/Jan/09 08:19 AM
Status In Progress [ 3 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Dejan Bosanac made changes - 19/Feb/09 06:45 AM
Status Resolved [ 5 ] Reopened [ 4 ]
Resolution Fixed [ 1 ]
Gary Tully made changes - 24/Jun/09 04:23 AM
Fix Version/s 5.3.0 [ 11914 ]
Fix Version/s 5.4.0 [ 12110 ]
Dejan Bosanac made changes - 05/Aug/09 07:48 AM
Resolution Fixed [ 1 ]
Fix Version/s 5.4.0 [ 12110 ]
Fix Version/s 5.3.0 [ 11914 ]
Status Reopened [ 4 ] Resolved [ 5 ]