[rabbitmq-discuss] Weird Crash (91MB message over STOMP) [Reproducible]

Sat Aug 8 09:29:49 BST 2009

>> 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:
>
> =INFO REPORT==== 8-Aug-2009::03:40:01 ===
> accepted TCP connection on 0.0.0.0:61613 from 127.0.0.1:50113
>
> =INFO REPORT==== 8-Aug-2009::03:40:01 ===
> starting STOMP connection <0.6224.0> from 127.0.0.1:50113
>
> =ERROR REPORT==== 8-Aug-2009::03:40:01 ===
> STOMP Reply command unhandled: {'basic.deliver',
>                                   <<"Q_500.manager.workers">>,

Actually, this problem is a bit worse.... apparently, when RabbitMQ
restarts and recovers the persister -- even persistent messages marked
'ready' on OTHER durable queues are NOT retrievable by other STOMP
clients.... I get the same type of error in the rabbit.log:

=ERROR REPORT==== 8-Aug-2009::04:21:16 ===
STOMP Reply command unhandled: {'basic.deliver',
                                   <<"Q_1.manager.workers">>,
                                   1,
                                   false,
                                   <<"events">>,
                                   <<"1.job.create.job.urls.job_alerts">>}

The unit test case for this would be:
1) Create a durable exchange
2) Create a durable queue
3) Bind the queue to the exchange
4) Make sure the queue has no consumers subscribed
5) Send a small (normal) persistent message to the queue
6) Crash RabbitMQ by sending a large message to a different, unrelated queue
7) Kill epmd
8) Restart RabbitMQ
9) Verify the (normal) message still exists via rabbitmqctl
10) Start STOMP consumer and attempt to subscribe to the queue
11) STOMP consumer waits, RabbitMQ generates the log message, but no
persistent (normal) message gets delivered

Let me know if this makes sense.... I'm thinking the STOMP adapter
doesn't know how to properly deal with recovered, persisted messages
in general... but I'd like to know if this is a general problem or a
specific one.

-- Darien