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 > -- View this message in context: http://www.nabble.com/Stomp-transactions-tp23354832p23355062.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.