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
