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 Tue, 15 Sep 2009 12:33:55 GMT
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).
>>
>> I.e. it would do pretty much what you describe, but through a simpler
>> interaction. The client would just need to 'subscribe' to the 'LVQ'.
>>
>> I would think that in JMS this would be made available as a Destination you
>> could create consumers and producers from for normal use. It would behave
>> more like a JMS topic than a queue though (i.e. consumers would not compete
>> for messages).
>>
>> Are there other views or use cases on what it should do?
>>
>>
> 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.


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


Mime
View raw message