FAQ
I am working on a project to manage custom attributes in the queue arguments
table and found that if I write to the rabbit_queue table it will reflect in
the management plugin as I want, without interrupting existing publishers or
consumers.

It seems like it does exactly what I want it to do, which is very cool but
I can't help but wonder if it's a bad idea though.

Would someone with a good handle on RabbitMQ internals mind taking a look at
my code and let me know if I have anything to worry about?

All write related functions use the write_record/1 function:

https://github.com/gmr/elmer/blob/master/elmer.erl#L98

And examples of use can be found in setup_monitoring/4 at:

https://github.com/gmr/elmer/blob/master/elmer.erl#L27

And toggle_monitoring/2 at:

https://github.com/gmr/elmer/blob/master/elmer.erl#L46

I'm currently working on a cli wrapper for these and plan on releasing this
and the accompanying Nagios integration bits if this is sane enough.

Thanks,

Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110512/609874ff/attachment.htm>

Search Discussions

  • Simon MacMullen at May 13, 2011 at 9:58 am

    On 13/05/11 04:06, Gavin M. Roy wrote:
    I am working on a project to manage custom attributes in the queue
    arguments table and found that if I write to the rabbit_queue table it
    will reflect in the management plugin as I want, without interrupting
    existing publishers or consumers.

    It seems like it does exactly what I want it to do, which is very cool
    but I can't help but wonder if it's a bad idea though.

    Would someone with a good handle on RabbitMQ internals mind taking a
    look at my code and let me know if I have anything to worry about?
    Depends how you define "bad idea". In terms of today's implementation
    you should be fine, as long as you don't expect (for example) to be able
    to flip the durability field and have that mean something.

    Of course, you're going very much behind the scenes here and anything
    you do today is not guaranteed to work tomorrow. Raymond Chen is not on
    our team. While I don't see anything on the horizon that would break
    this general property, you should should certainly be prepared for the
    schema to change.
    All write related functions use the write_record/1 function:

    https://github.com/gmr/elmer/blob/master/elmer.erl#L98

    And examples of use can be found in setup_monitoring/4 at:

    https://github.com/gmr/elmer/blob/master/elmer.erl#L27

    And toggle_monitoring/2 at:

    https://github.com/gmr/elmer/blob/master/elmer.erl#L46

    I'm currently working on a cli wrapper for these and plan on releasing
    this and the accompanying Nagios integration bits if this is sane enough.
    Cool, sounds interesting.

    Cheers, Simon
    --
    Simon MacMullen
    Staff Engineer, RabbitMQ
    SpringSource, a division of VMware
  • Matthew Sackman at May 13, 2011 at 12:10 pm

    On Fri, May 13, 2011 at 10:58:34AM +0100, Simon MacMullen wrote:
    Depends how you define "bad idea". In terms of today's
    implementation you should be fine, as long as you don't expect (for
    example) to be able to flip the durability field and have that mean
    something.
    It's a very bad idea. For one thing, Rabbit assumes that the queue
    record is unaltered after the queue has been created. Consequently the
    amqqueue_process process takes a copy of the #amqqueue record and holds
    it in its state. It never updates it. So if you change the copy in
    mnesia, then you subsquently have divergence between the queue process's
    copy, and the mnesia copy. This can lead to suprising results.

    For example if you issue amqqueue:info on a queue then it'll go through
    to the queue and not mnesia. Thus you'll find that results in management
    and in rabbitmqctl now don't match.

    You then have things like the property that queue redeclaration should
    fail if arguments do not match (semantically) the original declaration.
    But this only goes as far as mnesia. Consequently, you will have the
    queue, if you interrogate it, claiming its arguments are one thing, but
    if you try to redeclare the queue with those arguments, you can find
    it'll fail because the mnesia copy is different.

    Finally, you'll have the fact that if the broker is restarted, you'll
    have the queues recovered with their arguments taken from mnesia. So
    suddenly on startup, you'll have queues being restarted with different
    arguments from that which they were last running with.

    Matthew
  • Gavin M. Roy at May 13, 2011 at 4:13 pm
    Matthew,
  • Matthew Sackman at May 13, 2011 at 4:22 pm

    On Fri, May 13, 2011 at 12:13:13PM -0400, Gavin M. Roy wrote:
    From your perspective is there any way to do this that's not a bad
    idea while not impacting production queue use?
    No. There are implementation details of Rabbit that make the assumption
    this will never happen.
    Your points are valid,
    however since they're arguments and Rabbit doesn't care about or use
    arguments, I wonder how impacting it can be.
    Incorrect. Arguments can contain things like queue expiry, or queue
    message ttl, or any other extension to queue semantics that we dream up.

    That said, with some careful choice, you can be fairly sure to avoid
    choosing names that collide with anything we might do, and because
    arguments that Rabbit doesn't understand are not semantic altering
    anyway, Rabbit will ignore them.

    Matthew

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedMay 13, '11 at 3:06a
activeMay 13, '11 at 4:22p
posts5
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase