Stomp transactions

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Stomp transactions

volante
I'm a bit confused about some behaviour I'm seeing when doing transactions with stomp.

First my producer puts 3 messages into MyQueue: MSG1, MSG2, MSG3

Then I start up my stomp consumer which does this:

- CONNECT (ack = client)
- SUBSCRIBE MyQueue
- BEGIN tx1
- <reads a message> message-id: MSG1
- ACK message-id: MSG1

At this point, the message appears to be dequeued when I look at the queue via the admin web interface (that seems correct as it is locked by the transaction?).
Now, I kill my stomp client process, so the TCP connection is closed, mid-transaction.
The message now re-appears in the queue when looking at the admin web interface (makes sense to me..)

Now the strange behavior is, when I re-run my stomp client, and do the same series of steps, I now receive MSG2.  If I kill repeat the process I will then receive MSG3 and then finally it will block with no messages to receive.

I would have thought that since the transaction never finished and my TCP connection was terminated, the ACK should have been rolled back and my next client that connects should receive a retransmission of MSG1.

Can anyone explain what is going on here?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Stomp transactions

volante
Further to this,  it appears that if I restart activemq, new stomp clients will then receive the messages as expected (they are persistent messages).  If I send an ABORT before disconnecting the stomp connection, everything works as expected and no restart is required.  It looks like when I close the TCP connection mid-transaction, the message remains locked.  Is this a bug or is there a configurable timeout?
volante wrote
I'm a bit confused about some behaviour I'm seeing when doing transactions with stomp.

First my producer puts 3 messages into MyQueue: MSG1, MSG2, MSG3

Then I start up my stomp consumer which does this:

- CONNECT (ack = client)
- SUBSCRIBE MyQueue
- BEGIN tx1
- <reads a message> message-id: MSG1
- ACK message-id: MSG1

At this point, the message appears to be dequeued when I look at the queue via the admin web interface (that seems correct as it is locked by the transaction?).
Now, I kill my stomp client process, so the TCP connection is closed, mid-transaction.
The message now re-appears in the queue when looking at the admin web interface (makes sense to me..)

Now the strange behavior is, when I re-run my stomp client, and do the same series of steps, I now receive MSG2.  If I kill repeat the process I will then receive MSG3 and then finally it will block with no messages to receive.

I would have thought that since the transaction never finished and my TCP connection was terminated, the ACK should have been rolled back and my next client that connects should receive a retransmission of MSG1.

Can anyone explain what is going on here?

Thanks
Reply | Threaded
Open this post in threaded view
|

Re: Stomp transactions

Murphy Meng
After 9 years, this interesting post had no comments or explainations. I just
test and verified activeMQ still works the same way, which I think is
problematic.

Any more thoughts?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Stomp transactions

Tim Bain
Have you confirmed that the broker host (at the OS level) doesn't believe
that the TCP connection is still alive at the time you're saying the broker
is wrongly failing to deliver the message to a new client? If you
ungracefully terminate a TCP connection, the remote side (the broker in
this case) can only detect that fact after the TCP timeout has elapsed
without receiving more bytes across the connection. So if you did your test
before that window has elapsed, then the behavior you described would be
correct. If you've waited long enough that your broker's OS shows the TCP
connection as closed and you get the behavior you describe, then that
sounds like a bug and I encourage you to submit a bug in JIRA for it.

Tim

On Thu, Nov 15, 2018, 7:45 AM singlaive <[hidden email] wrote:

> After 9 years, this interesting post had no comments or explainations. I
> just
> test and verified activeMQ still works the same way, which I think is
> problematic.
>
> Any more thoughts?
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>