2009/9/16 Gordon Sim <[email protected]> > 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. > > For the Java Broker, as I said previously, I have a patch which I wrote ages ago which I'm planning on applying before the 0.6 release... I'll probably switch my attention to that once I've finished my work in implementing AMQP0-10 on the Java Broker...
-- Rob
