[rabbitmq-discuss] STOMP adapter lose the last message of a burst
jose.mico at gmail.com
Fri May 18 15:56:36 BST 2012
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
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?
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1472 bytes
Desc: not available
More information about the rabbitmq-discuss