[rabbitmq-discuss] STOMP adapter lose the last message of a burst

Tue May 22 10:38:08 BST 2012

José,

Thank you for all the investigation you are doing. I have caught up and
yesterday convinced myself that it is indeed our bug. The Wireshark
traces confirm that all the messages are actually sent. I have produced
my own version of your testcase with numbered messages to test which
ones fail to get through. I've also ended the app with a DISCONNECT, but
still we lose one of the messages.

I'm going to look more closely at the STOMP stuff, and have raised a bug
(24957) to track this internally. I'll get back to you as soon as I find
out where this is getting lost.

Incidentally, it is apparently the last message in a packet that is not
being picked up, and it is not obvious why this should be so. Putting
the DISCONNECT on the end I thought would cure it, but it didn't; which
is very strange. Of course, I don't wait for a receipt on the
DISCONNECT; but closing too soon is not the problem.

Steve Powell  (a happy bunny)
----------some more definitions from the SPD----------
chinchilla (n.) Cooling device for the lower jaw.
socialcast (n.) Someone to whom everyone is speaking but nobody likes.
literacy (n.) A textually transmitted disease usually contracted in childhood.

On 22 May 2012, at 01:23, José Micó wrote:

> Forget my suggestion about process_received_bytes(), I was looking at the wrong repository, ha.
> 
> Well, here is attached the best test case I got so far: a Python script that sends very quickly 1001 messages, the first 1000 ones to queue "stomp_bug" and the last one to another queue "stomp_bug_last".
> 
> Running it several times, can be found that sometimes the last message is lost (and only the last message).
> I've executed it 20 times, and got only 10 messages into queue "stomp_bug_last".
> 
> I looked at the actual source code in mercurial, and I really cannot help with that...
> 
> 
> José
> <stomp_bug_2.py>