[rabbitmq-discuss] Lost message in 50k size range
john at ibiblio.org
Tue Mar 6 18:13:42 GMT 2012
In this case, lost means the consumer never gets it. I have a test
setup for debugging. Both publisher and consumer are python/pika.
The publisher sends 2 messages -- one is a bson encoded python string
of length 49144, the other is 49145. The consumer gets the first
message but not the second. It's the same behavior for messages down
to 1 byte and up to a few 100 KB. The failure point seems to be at
this 49145 length.
Other useful information may be that queue durability and message
delivery mode settings don't affect the behavior. Also, your
suggestion of publishing to a consumerless queue didn't result in a
queued message, as far as I can tell.
I'm using the management and tracing plugins, turned on tracing, and
turned on pika debug logging. I can't find any errors or indication
of why the message disappears or where it's going. I'm not sure I
know the right places to look, though.
On Tue, Mar 6, 2012 at 12:24 PM, Gavin M. Roy <gmr at myyearbook.com> wrote:
> I regularly send much larger messages. How are you determining the message
> is lost?
> Have you tried setting up a stand-alone queue with no consumers and
> publishing the messages to it? And are you using the management plugin? The
> UI is a good way to inspect that kind of stuff.
> On Tuesday, March 6, 2012 at 11:48 AM, John Reuning wrote:
> I'm using pika to send and receive bson-encoded binary data through
> rabbitmq. Pika 0.9.5, rabbitmq 2.7.1. Everything works until the
> message body goes over 49144 characters. The message disappears into
> the void at 49145 characters. The content of the message doesn't seem
> to matter, but I've not tested that extensively. The encoding is set
> to application/octet-stream.
> Pika debug logging shows the message split into multiple frames and
> sent to rabbitmq. Trace logs don't show any activity. Increasing
> frame_max didn't help. Does anyone have suggestions on how to debug
> this or what might be going wrong? I'd rather not resort to tcpdump.
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss