qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Godfrey <rob.j.godf...@gmail.com>
Subject Re: Java/JMS LVQ interaction
Date Wed, 16 Sep 2009 08:18:14 GMT
2009/9/16 Gordon Sim <gsim@redhat.com>

> 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.
>
>
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message