[rabbitmq-discuss] a common-lisp amqp client

James

Thanks very much. Your docs seem very thorough. One niggle: you may
wish to change "Apache ActiveMQ" to "OpenAMQ" since the former does
not implement AMQP, while the latter was in fact the first
implementation.

If you have more comments about interoperability please do keep
posting them here. As we converge on 0-91 implementations, your work
will be increasingly helpful in establishing cross-broker conformance.

alexis

James

I also note your comment "The implementation architecture should also
accommodate a control structure appropriate for the prospective 1.0
version - as least as described in preliminary drafts."

If you want to get involved in any 1.0 work, please do let me know.

alexis


On Wed, Feb 17, 2010 at 10:10 AM, Alexis Richardson
wrote:

good evening;
as it were, i do have one.

one may recall, i had enquired some time back, about the intended
mechanism to stream data through a channel.
there were a few responses. of which one was a concrete suggestion,
it was unsatisfactory.
upon reflection, it should be possible to do this portably, in a way
which at least reflects standard practice elsewhere, and without an
extra message.
in fact, the conceived mechanism does work with qpid.
the details - both an explanation of the mechanism and connection
transcripts, are in a note online.[1]

the log output is dense, but the bottom line is, rabbitmq suppresses
zero-length frames.
as demonstrated by this manner to implement chunking, these frames
most definitely carry information.
in which case, i am surprised the broker is permitted to drop them.

is there a reason the server does this?
can this be corrected through reconfiguration?

---
[1] http://github.com/lisp/de.setf.amqp/blob/master/examples/README-
streaming.md

James,

james anderson wrote:
This isn't a case of the broker dropping frames but
re-chunking/re-framing content. 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.


Regards,

Matthias.

the transcript did not indicate that there was any reframing.
the two frames with non-zero length were forwarded as published.
if that were to apply.
and where a writer and a reader agree on a frame size?
anyway, it seems quite peculiar for a broker to muck with the
clients' data without cause.
is there any way to turn it off?

James,

james anderson wrote:
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.
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.
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.
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.

good evening;
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
4.2.6.2 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.

James,

james anderson wrote:
Indeed the frames do all arrive intact and in that order. But that is
all happening within the context of a specific channel and in a specific
direction, i.e. client-to-server or server-to-client.
No idea, and note that the paragraph refers to *aborting* the sending of
content, not terminating, so it wouldn't help in what you are trying to do.
The content bodies referred to in section 3.1.1. refer to logical AMQP
method content, not any particular chunking of it into content frames.


Regards,

Matthias.