qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wright <atwri...@mac.com>
Subject Re: Java/JMS LVQ interaction
Date Tue, 15 Sep 2009 19:39:50 GMT

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)

Cheers,
Andrew

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message