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

[José Micó]

On 05/21/2012 08:04 AM, Steve Powell wrote:
> I can reproduce your bug locally with 100 messages, but with 50 messages
> it doesn't seem to happen.
Thanks for reproducing the bug :-)

This does not happens with bursts of few messages. I can reproduce it 
with burst over 100, and almost always fail with bursts of 10000. As I 
stated in a previous mail, this is related to the CPU load of the 
broker: to trigger the bug, the broker must be busy. Is more probably to 
trigger it with 1000 mesages of 1 KB than with 10 messages of 100KB.
> Your testcase isn't clear about which of the
> messages it is losing. I suspect it is one of the first set of 100.
The test case does not show which message is missing. But in other tests 
that I have in my test suite I found that the lost message is always the 
last one, and only the last one.
> 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 will look at Wireshark, but I am almost sure that the perl app sent 
the data to the kernel. I don't know what the kernel does then.
> Autoflush() appears to make no
> difference, and autoflush(1) in the loop (after the 100 messages) also
> doesn't cure the problem.
>
> I modified your test a little to put in a rolling -123456789, rather
> than all X's, to check what is in the end of the buffer, and I note that
> the last data buffer sent was short.
I've attached a python version of the test script, which shows the same 
symptoms than the perl one.
This time, the body of message contains the message number and and END 
mark to help sniffing.
> If I include a DISCONNECT at the end, this doesn't improve. (Note that
> after the test has run one message is missing.)
>
> There appears to be some glitch in which a buffer/packet is not sent.
>
> I'm accumulating a Wireshark trace of this; but it appears to me that
> this is a Perl client problem.
Python does the same. And if it is a perl problem, why my app works fine 
on Apollo?
> My next questions are as follows: When you tested with Apollo, are you
> using exactly the same perl? and libraries? and testcase?
I've used exactly the same enviroment, code and everything (the beauty 
of interoperability :), only with an instance of Apollo running instead 
of RabbitMQ.
I've just doubled checked it.
> Have you tried
> this test with a different client library (say, Python instead of Perl)?
I've attached a Python version of the test case. Same happens: It send 
1000 messages, sometimes only 999 are queued.
> At the moment I cannot see or detect any STOMP adapter problems which
> might account for this problem.
I don't know if this affects AMQP also. Just happens that I am using the 
STOMP adapter.


Thanks for your time,
José

> 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 19 May 2012, at 22:37, José Micó wrote:
>
>> I've just confirmed this bug running my app against another broker (Apollo), on which the app worked perfectly.
>> Do you have any plan to fix this bug? I can test development versions of the plugin, if you want.
>>
>> Regards,
>> José
>> _______________________________________________
>> 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.py
Type: text/x-python
Size: 1299 bytes
Desc: not available
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120521/2c8e9a64/attachment.py>