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

[José Micó]

I've continued tracing the issue of STOMP adapter buffering the last 
message of a burst, and found that:

- The busier the CPU of the broker, the easier is to replicate the bug 
(this is a symptom of a race condition?)
- The size of messages doesn't seems to affect very much the outcome.
- The number of messages in the burst increments the possibility of a 
failure.
- I slowly sent carefully fragmented STOMP frames, there was no problem. 
The parser seems to cope with that fine.
- When the bug is triggered, the last message remains buffered at 
connection level. Other connections can publish to the queue perfectly.
- In my developement notebook I consistently get a failure ratio over 
30% for bursts of 100, 1000 or 10000 messages.

I've attached the flood script that I'm using for testing different 
combinations of message counts and sizes.
Maybe there is a problem within this script, but I doubt that as I get 
the same behavior with two different frameworks, and exactly one message 
is lost independently of message size.

This is causing me problems on the following cases:

- I want to notify 100 subscribers of a given event.
   Sometimes, first 99 are notified but the last one is not until the 
event is triggered again, but then it is too late.

- I want to send 100 RPC style requests and wait for the results.
   Sometimes, only 99 results are received because the last request was 
never sent.

- I want to notify 100 subscribers of a given event, and immediately 
send an RPC style request.
   Sometimes, subscribers are notified but the result of the RPC request 
is never received, as the last request was actually never sent.

As a workaround I could throttle the sending of messages, but that is 
really difficult as I don't have control on how the kernel flushes the 
tcp write buffer.
And, how much delay should be added to be safe? 50ms? That will make a 
client to take 50 seconds to send 1000 messages...

Is anybody getting STOMP message drops with 2.8.2? Can anyone replicate 
this bug?

Regards,
José

-------------- next part --------------
A non-text attachment was scrubbed...
Name: stomp_bug_3.pl
Type: application/x-perl
Size: 2097 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120519/17ccca9b/attachment.bin>