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 Tue, 15 Sep 2009 12:13:33 GMT
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).


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