Note: This is a new message where I've pasted in text from the mailing
list archives rather than a direct reply, as I seem to have stopped
receiving messages to the list again.
On 08/25/2011 01:05 PM, Toralf Lund wrote:
> I'd now like to turn to the "initial value" behaviour for exchanges. Can
> anyone explain what exactly this means? Is the mechanism documented
> anywhere? Obviously, I understand that an exchange with this behaviour
> will store some values in addition to forwarding them to queues but what
> exactly does it keep? Only one message for the entire exchange? Or one
> per routing key? Or something else entirely?
Only one message for the entire exchange.
OK. It won't be useful in this context, then...
> Maybe should explain exactly what I'm trying to do, so that it will be
> easier to say if this behaviour is appropriate for my needs:
> I won't go into details, but essentially I'm setting up a server, or
> publisher if you like, that will distribute different status readings
> from external hardware to one or more client application. [ ... ]
So at any point in time each hardware unit has a value for several
different categories of status?
Precisely!
> What setup(s) would be appropriate in this case? My current prototype
> implementation has:
>
> * One topic exchange.
> * One routing key (topic) per status value.
> * A hardware unit identifier stored as a custom message property.
> * A last-value queue per topic, using the above mentioned property
> as "last value queue key". This is shared between clients, which
> will only ever browse messages.
>
> It seems like this might be a way forward, but it does have some issues,
> notably that it only works correctly if the queues are created and
> correctly bound to the exchange before the publisher is started, and are
> kept that way throughout its lifetime.
What is your concern here? That the broker would crash and lose the
queues? That there would be configuration error? That someone would
delete or unbind the queues?
I'm worried about all of those, I guess. Maybe we have to assume
everything is configured correctly and that someone won't go in and
delete the queues just like that, though - broker crash becomes the main
concern, then.
It would be nice to be notified somehow on the publisher side if
messages to a certain topic is no longer routed anywhere, but in a way,
allowing that kind of thing would break with some of the principles
behind AMQP...
It may not address your concerns, but another suggestion would be to use
the combination of hardware unit identifier and status as a property on
each message and use that combined property as the key for a single
last-value queue. All this really offers is simplicity of configuration;
i.e. one queue that the publisher sends to and that the subscribers
browse. It would however mean you couldn't simply request the values for
a particular category of status.
Yes, that's another option, of course. There would at least be fewer
queues to worry about then. Whether it's important to be able to find
messages for one category without having to filter messages is something
I need to think about some more. It isn't really today, but I'm trying
to plan ahead... There is also a minor performance question, I suppose.
The current approach probably uses more resources on maintaining queues
and routing messages to them, but the "last value" check will presumably
be more efficient - so which method is better in total?
Thanks,
- Toralf
> Would an initial value exchange be appropriate in such a scenario? And,
> do you think it would make it easier to get a robust setup? I mean,
> ideally, the publisher should re-issue the last samples if a problem has
> occurred. This is no problem as such as the data is still available on
> the server-side, but how do I know that I have to re-send it?
This e-mail, including any attachments and response string, may contain
proprietary information which is confidential and may be legally privileged. It
is for the intended recipient only. If you are not the intended recipient or
transmission error has misdirected this e-mail, please notify the author by
return e-mail and delete this message and any attachment immediately. If you
are not the intended recipient you must not use, disclose, distribute, forward,
copy, print or rely on this e-mail in any way except as permitted by the author.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
