[rabbitmq-discuss] a common-lisp amqp client
matthias at lshift.net
Wed Feb 17 22:06:08 GMT 2010
james anderson wrote:
> the transcript did not indicate that there was any reframing.
> the two frames with non-zero length were forwarded as published.
That just means the re-framing in that case was sub-optimal - the broker
only dropped the zero length frame but left the others unchanged. What
version of rabbitmq are you running? In 1.7.2 the re-framing is more
>> That is something a broker is permitted to do and in some cases
>> even has to do since the negotiated max frame size on the publisher
>> connection and consumer connection may be different.
> if that were to apply.
> and where a writer and a reader agree on a frame size?
Even if the publisher and consumer connection happen to have the same
negotiated frame size, the server is still entitled to re-frame the content.
> anyway, it seems quite peculiar for a broker to muck with the
> clients' data without cause.
You are conflating layers here, which admittedly aren't particularly
well-defined in the AMQP specs. Framing is a transport-level concern; it
does not appear at the application level. Think of the framing as the
same kind of thing your tcp stack does when deciding how to split up a
data stream into packets.
Now, atm AMQP only defines one transport, but that will change. In fact
RabbitMQ already exposes AMQP over other transports like HTTP and SMTP,
and we have gateways to STOMP, etc. Most of these have no notion of framing.
> is there any way to turn it off?
Not without changing the code. If you want to experiment with this, the
place to look is rabbit_binary_generator:build_content_frames, iirc.
More information about the rabbitmq-discuss