On 2010-02-17, at 23:06 , Matthias Radestock wrote:
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,
ok. if there were any other way to do this without incurring
unnecessary overhead, i'd not be so vocal.
problem is, as you note above, the layers are less than clear, and,
in fact all thrown into the clients lap to disambiguate. in the
process of which, i had gathered the following from the specifications.
i had read the passages at the bottom of amqp0-9-1.pdf/page 35 to
imply that, if frames are strictly sequential, they would also
continue to exist. frames sent as 1,2,3 and arriving as 1,3 don't
fall in my classification of a strict order. it is difficult to think
about a strict ordering between sets with - as you describe, disjoint
constituents. if the intent is to specify an order for the content of
the body frames, the specification could be rephrased to say that.
the next paragraph on that page implied that there might be an
alternative to using a zero-length frame to carry early termination
information, but i could not make out any command which could be sent
proactively to actually have the described effect without additional
disruption. what kind of termination was this passage intended to imply?
i had read the last paragraph of 3.1.1 on page 26 to limit, if not
preclude, the actions which you describe. yes, there is a possible
conflict between that paragraph and the passage at the close of
22.214.171.124 on page 36, but the "MUST NOT"s in the earlier passage are
neither lightweight nor contingent stipulations, and, as
demonstrated, the practice most certainly removes information.
in any case, thank you for the pointer.