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

[José Micó]

On 05/21/2012 08:04 AM, Steve Powell wrote:
> So I installed Wireshark (are you familiar with this tool?) and looked
> at the message traffic. As far as I can see the last buffer is NOT sent
> to the broker from the perl app.

I installed Wireshark and done some captures while running the Python 
script that I've sent before, for bursts of 100 and 1000 messages, both 
for cases of successes and failures (captures attached). Note that sent 
messages are numbered starting from 0, so the last message of the burst 
are #99 or #999.

I can see in all captures that the last packet sent ends correctly on 
"00099/END" or "00999/END" followed by NIL. So, the Python script is 
actually sending all messages to RabbitMQ.

So, I think that...

- The data is sent to Rabbit.

- Rabbit receives all packets, because the last packet contains several 
messages, not only the last one.

- Rabbit *always* process correctly messages 00098 and 00998, so the 
parser receives the data of the last packet.

- The last message remains buffered somewhere (is not actually lost) but 
is not sent timely to the queue. If more data is sent later on the same 
connection, then that message is added to the queue. If connection is 
closed, the message is lost.

I guess that this is caused by a race condition, because the bug is not 
always triggered and only happens when the broker is stressed.

My next step would be to add some debug statements to 
process_received_bytes() in rabbit_stomp_server.erl, but I really have 
not clue about Erlang :-(


José

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stomp_bug_captures.tar.gz
Type: application/x-gzip
Size: 27773 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120521/6a7f7485/attachment.bin>