FAQ

[rabbitmq-discuss] a common-lisp amqp client

James anderson
Feb 17, 2010 at 2:26 am
good morning;

with adjustments made as per the responses to my earlier questions
about rabbitmq and 0.8r0 brokers in general, i was able to connect
and exchange elementary messages with the 1.7.1 version of the
rabbitmq broker[1]. thank you for your assistance.

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

Search Discussions

8 responses

  • Alexis Richardson at Feb 17, 2010 at 10:10 am
    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



    On Wed, Feb 17, 2010 at 2:26 AM, james anderson wrote:
    good morning;

    with adjustments made as per the responses to my earlier questions
    about rabbitmq and 0.8r0 brokers in general, i was able to connect
    and exchange elementary messages with the 1.7.1 version of the
    rabbitmq broker[1]. thank you for your assistance.

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


    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
  • Alexis Richardson at Feb 17, 2010 at 10:16 am
    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:
    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



    On Wed, Feb 17, 2010 at 2:26 AM, james anderson wrote:
    good morning;

    with adjustments made as per the responses to my earlier questions
    about rabbitmq and 0.8r0 brokers in general, i was able to connect
    and exchange elementary messages with the 1.7.1 version of the
    rabbitmq broker[1]. thank you for your assistance.

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


    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
  • James anderson at Feb 17, 2010 at 7:36 pm
    good evening;
    On 2010-02-17, at 11:10 , Alexis Richardson wrote:

    James

    [...]

    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.
    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
  • Matthias Radestock at Feb 17, 2010 at 8:27 pm
    James,

    james anderson wrote:
    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.
    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.
  • James anderson at Feb 17, 2010 at 9:33 pm

    On 2010-02-17, at 21:27 , Matthias Radestock wrote:

    James,

    james anderson wrote:
    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.
    This isn't a case of the broker dropping frames but re-chunking/re-
    framing content.
    the transcript did not indicate that there was any reframing.
    the two frames with non-zero length were forwarded as published.
    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?
    anyway, it seems quite peculiar for a broker to muck with the
    clients' data without cause.
    is there any way to turn it off?
  • Matthias Radestock at Feb 17, 2010 at 10:06 pm
    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.
  • James anderson at Feb 17, 2010 at 11:03 pm
    good evening;
    On 2010-02-17, at 23:06 , Matthias Radestock wrote:

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





    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100218/f804393d/attachment.htm
  • Matthias Radestock at Feb 17, 2010 at 11:26 pm
    James,

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

Related Discussions

Discussion Navigation
viewthread | post