[rabbitmq-discuss] Weird Crash (91MB message over STOMP) [Reproducible]
Matthias Radestock
matthias at lshift.net
Sat Aug 8 09:33:02 BST 2009
Darien,
Darien Kindlund wrote:
> Hi Matthias,
>
>>> Okay, so after enabling verbose logging, I was able to replicate the
>>> error, reliably.
>> including the "messages show up as unacknowledged after restart" problem?
>
> YES. I think this problem is also STOMP specific! After recovering
> the persister from the last crash. I start up a single STOMP client
> and attempt to subscribe and get the first message off the queue. At
> that time, rabbit.log generates this error:
Hang on. At what point do you see the unacknowledged messages? Right
after the restart? (and how? with 'rabbitmqctl list_queues'?) Or after
you start up that single STOMP client?
I am asking because when I recover your latest db dir into my rabbit
instance I see three *ready* messages in the '500.manager.workers' queue.
> =ERROR REPORT==== 8-Aug-2009::03:40:01 ===
> STOMP Reply command unhandled: {'basic.deliver',
> <<"Q_500.manager.workers">>,
> 1,
> false,
> <<"events">>,
> <<"500.job.create.job.urls.job_alerts">>}
> {content,60,
> none,
> ... followed by the entire message contents...
That may well be a bug. Can you send me just a little bit more of the
above error? Another k or so should do.
>> You say rabbit died with zero logging. That may well be true, but rabbit
>> *did* produce a crash dump, and that should allow us to establish the cause
>> of death.
>
> Okay, good to know.
It ran out of memory, which is what I suspected.
> This is interesting. So I resent the large message with
> 'delivery-mode' of '1' instead of '2' (which should make it NOT
> persistent -- right?). RabbitMQ still dies.
Interesting indeed. Yes, that means the persister is unlikely to be the
causing the OoM.
Regards,
Matthias.
More information about the rabbitmq-discuss
mailing list