ActiveMQ
  1. ActiveMQ
  2. AMQ-1807

Activemq stops dispatching messages aborting transaction (STOMP)

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 5.1.0
    • Fix Version/s: 5.3.0
    • Component/s: Transport
    • Labels:
      None
    • Environment:

      Linux, JDK 1.6_06b2

      Description

      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.

        Activity

          People

          • Assignee:
            Dejan Bosanac
            Reporter:
            Celso Pinto
          • Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development