On 09/15/2009 08:39 PM, Andrew Wright wrote:
On 15 Sep 2009, at 13:33, Gordon Sim wrote:
On 09/15/2009 01:13 PM, Robert Godfrey wrote:
Hi Gordon,
2009/9/15 Gordon Sim<[email protected]>
I think clunky is a fair description of the current capabilities and I
think we can improve on that.
My view of what ideal 'LVQ' behaviour whould be like is that the
'queue'
would really be more like a 'topic' where the last message for each
key was
always saved. Clients would subscribe to it and receive the last
message
published for each key and subsequently any updates (i.e. any new
messages).
The above is pretty much how I would like an LVQ to behave... Indeed
I have
a patch for the Java Broker to provide just such LVQ functionality,
which I
should get round to applying for 0.6. The only real question is do you
inform subscribers of *all* updates... or, if the subscriber starts
to fall
behind, do you only send updates that have not themselves already been
superceded (my Java implementation does the latter).
I think the latter sounds reasonable.
Absolutely - your description sounds spot-on. That would certainly be
very useful behaviour (it would greatly simplify our current application
code). Consumers could be artificially throttled to reduce processing
requirements if things got busy.
The only other use case I can imagine would be calling into the broker
on an ad-hoc basis, supplying a key and being returned the message that
currently matches that key, or null if there never was one. That could
perhaps be useful in very high update rate scenarios, where you'd want
the broker to bear the work of maintaining the queue without making
clients receive every (or even every few) messages. Admittedly this does
go away somewhat from a 'messaging' based scenario and more towards a
'remote-cache' style behaviour, not sure if that would be of concern.
Dare I wonder out loud what might be involved in hooking this up? (java
client/c++ broker combination of particular interest for us)
Its not a trivial change I'm afraid, and would require some initial
refactoring around the c++ brokers queue implementation. However in my
opinion it would be a very worthwhile task and I'll turn my attention to
it as soon as I can. I've created a Jira at
https://issues.apache.org/jira/browse/QPID-2104, feel free to add any
comments or re-assign.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
