qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Java/JMS LVQ interaction
Date Wed, 16 Sep 2009 07:51:04 GMT
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<gsim@redhat.com>
>>>
>>>> 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:users-subscribe@qpid.apache.org


Mime
View raw message