[
https://issues.apache.org/activemq/browse/AMQ-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53676#action_53676
]
Dejan Bosanac commented on AMQ-1807:
------------------------------------
Hi Celso,
I think you're confusing transaction rollback and death of consumer.
In case when consumer dies, the broker will detect it and will append all
messages that are dispatched but not acknowledged by that consumer (all the
messages you have acked in the transaction that hasn't been committed) to the
end of the dispatch list. So these messages will be redelivered again to
another consumer eventually. This works now in the same way for JMS and Stomp
clients.
But when we rollback the transaction, we say to the broker that we haven't yet
consumed messages that were delivered to us. So the broker will wait for those
messages to be acked before sending more messages. This also works in the same
way for Java and Stomp clients, it's just that JMS Java client has built-in
logic that will try to redeliver those messages first (locally) when you start
a new transaction. You can also implement the same logic in your Stomp client
(or application).
The whole point is that redelivery of messages after the rollback, is the task
for the client, since there's no need for the broker to resend those messages
over the network again.
Hope this helps,
Dejan
> 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.
