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

[José Micó]

On 05/18/2012 07:22 AM, Steve Powell wrote:
> This may very well be a bug, but could also be something about flushing
> in the Perl script you are using.
That was my first thought also (a client side buffering issue). I'm 
implementing a messaging framework, and while stress testing it I found 
that it fails consistently to deliver timely the last message sent to a 
topic or queue. Some of my tests fails frequently when the number of 
messages sent doesn't match the number of messages received, or when RPC 
style calls timeout due to the call istself not being sent timely.

Finally I could trace the bug down to RabbitMQ, and to be sure I wrote 
the simplest possible script that replicates the problem. I've attached 
an updated version of it which uses syswrite() calls in order to bypass 
any IO buffering.

I want to clarify that the last message is not actually lost: it remains 
buffered by the adapter, but is not processed until new data arrives 
from the same client.
If I send 100 messages, the queue will get messages #1..#99 (the last 
one being buffered somewhere). Then send another 100 messages, and queue 
will get the message #100, followed by #101..#199. Again, message #200 
remains buffered. And so on.

>
> Please can you tell us which version of RabbitMQ and STOMP you are
> using?
I'm using RabbitMQ 2.8.2 on Erlang R15B with the bundled STOMP adapter.

> Steve Powell
> steve at rabbitmq.com
> [wrk: +44-2380-111-528] [mob: +44-7815-838-558]
>
> On 18 May 2012, at 06:18, José Micó wrote:
>
>> I think I've found a somewhat serious bug in the STOMP adapter: after a burst of incoming messages, the last one remains buffered somewhere indefinitely and is not added to the queue until another message is received from the same connection (same with topics). This cause and excessive delay to deliver the message to consumers, if it is ever delivered. Besides that, that last message is lost if the connection is not properly closed.
>>
>> I've attached a simple script which replicates the bug. It sends burst of 100 small messages to a queue every 10 seconds. Using the management console, we can inspect the count of Ready messages. The expected progression is 100 ... 200 ... 300 ... 400 ... 500, but very frequently (not always) we get 99 ... 199 ... 299 ... 399 ... 499, as the last message is not queued.
>>
>> Could be that the STOMP parser gets confused after an incomplete frame was read from tcp buffer? Any ideas?
>>
>> Regards,
>> José
>> <stomp_bug.pl>_______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stomp_bug_2.pl
Type: application/x-perl
Size: 1472 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120518/40e977b9/attachment.bin>