[rabbitmq-discuss] a common-lisp amqp client

[Matthias Radestock]

James,

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 
aggressive.

>> 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.


Regards,

Matthias.