[rabbitmq-discuss] Weird Crash (1M to 10M messages over STOMP?) - Recovery logic for durable messages/queues/exchanges?

[Darien Kindlund]

Hi Matthias,

>>> Can you send me a copy of the rabbit.log?
>>
>> Yup, will do in a separate email to you.
>
> What's interesting here is that within one second of the TCP listener
> starting there are three AMQP (not STOMP) connections. STOMP connections get
> established ~80 seconds later.
>
> Could it be possible that the three initial AMQP connections consume from
> the queues? That would explain why you are seeing unacknowledged messages in
> the counts.

Those three AMQP connections don't subscribe to the same queue as all
the STOMP connections.  In fact, all three AMQP connections just
subscribe to their own, independent queues.  To be clear all the STOMP
connections share the same queue, which is the one that usually has
the un-ack'd messages.

At this point, I'm thinking you probably need more information to
replace the message un-ack'd issue.  Perhaps if we can nail down the
original culprit for the weird crash, then we can replicate the
un-ack'd issue.  If I can construct the original message sent via
STOMP which caused RabbitMQ to die unexpectedly... I'm thinking that
would be enough to replicate... right?  In any event, I'm working on
this and it will probably take 1-2 hours to complete.

>> Have you guys done any sort of unit testing with various message
>> sizes?  I'm guessing for AMQP, you have, but I'm wondering if you've
>> done the same for all the different protocols you guys support with
>> extensions (e.g., HTTP, STOMP ...).
>
> Tony may know the answer to that one... but one reason why the STOMP
> extension still has experimental status is that we haven't done any
> extensive testing.

Yeah, that makes sense.  Okay, I'll try to get the example message I'm using...

-- Darien