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).
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:[email protected]
