hi,

As previously mentioned, I'm trying to abuse the C librabbitmq in order
to develop an AMQP application in an event-based manner.

Tony Garnock-Jones' rais project has been helpful here, but it seems
that in order to send frames to an output buffer, it makes use of the
amqp_send_frame_to() function. However, it looks like[1] this function
has been eliminated from librabbitmq last October.

Is there any chance of amqp_send_frame_to() coming back? Or is there any
other suggested way to make librabbitmq construct a frame without
immediately sending it onto the socket?

It is possible that for our application the frames are generally going
to be small, so we might only call amqp_send_frame() when the socket is
ready for writing and hope that the send() call inside there won't ever
block (or return EWOULDBLOCK). But this seems fragile, to say the least.

thanks a lot,
mlc

[1]
https://github.com/rabbitmq/rabbitmq-c/commit/e50a94ba2fd471c61509ed3120f42d4506d99ffb

Search Discussions

  • David Wragg at Feb 16, 2011 at 11:26 am
    Hi Mike,

    mike castleman <m at mlcastle.net> writes:
    Is there any chance of amqp_send_frame_to() coming back? Or is there any
    other suggested way to make librabbitmq construct a frame without
    immediately sending it onto the socket?

    It is possible that for our application the frames are generally going
    to be small, so we might only call amqp_send_frame() when the socket is
    ready for writing and hope that the send() call inside there won't ever
    block (or return EWOULDBLOCK). But this seems fragile, to say the
    least.
    rabbitmq-c development is focused on its use as a self-contained AMQP
    client. We try to preserve the API functions aimed at typical AMQP
    client applications, rather than ones that seem more like librabbitmq
    internals (as this makes evolving the library difficult - librabbitmq
    exposes way too much of its internals, IMHO).

    (There's a trade-off in library design, particularly for C: One option
    is that library can expose clearly designated public APIs. The upside
    is that further development of that library is easy - you simply have to
    make sure that you preserve the APIs an their behaviour. The downside
    is that the library can only really support the use cases envisaged when
    those APIs were designed. The other option is to expose more or less
    everything, and allow applications to use the library as a "toolbox".
    The upside here is that is it probably possible to make the library
    serve a wide range of use cases, as applications can borrow whatever
    functionality is relevant and ignore the rest. The downside is that
    this tends to freeze the implementation, and would make it difficult to
    provide good documentation.)

    Perhaps the appropriate thing is to fork a version of rabbitmq-c that
    meets your needs on github?

    With that said, if we received a nice patch that restored
    amqp_send_from_to (and we'd need the author to sign our contributor
    agreement), I expect we would incoporate that. But I can't promise that
    we wouldn't remove the function again later on.

    As I may have mentioned before, it is our goal to release a C client
    that does support non-blocking support nicely at some point in the
    future. But this is likely to be done by having an API specifically
    designed for that use case.

    David

    --
    David Wragg
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 16, '11 at 1:49a
activeFeb 16, '11 at 11:26a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

David Wragg: 1 post Mike castleman: 1 post

People

Translate

site design / logo © 2022 Grokbase