Re: [jira] Commented: (QPID-2104) Improved LVQ implementation
On 02/21/2011 09:50 AM, Gordon Sim wrote: On 02/21/2011 02:40 PM, Carl Trieloff wrote: On 02/21/2011 07:01 AM, Gordon Sim (JIRA) wrote: Note: this implementation does not force all consumers to be browsers (may revisit that decision at some point). This comment raises a question for me. Are you assuming messages are just replaced by key but never dequeued? I know of many apps that want to have FIFO dequeue behaviour and the ability to be able to replace a message of key if not dequeued or acquired yet. Can this be still be achieved with the new impl? Yes. thx - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2104) Improved LVQ implementation
On 02/21/2011 02:40 PM, Carl Trieloff wrote: On 02/21/2011 07:01 AM, Gordon Sim (JIRA) wrote: Note: this implementation does not force all consumers to be browsers (may revisit that decision at some point). This comment raises a question for me. Are you assuming messages are just replaced by key but never dequeued? I know of many apps that want to have FIFO dequeue behaviour and the ability to be able to replace a message of key if not dequeued or acquired yet. Can this be still be achieved with the new impl? Yes. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [jira] Commented: (QPID-2104) Improved LVQ implementation
On 02/21/2011 07:01 AM, Gordon Sim (JIRA) wrote: Note: this implementation does not force all consumers to be browsers (may revisit that decision at some point). This comment raises a question for me. Are you assuming messages are just replaced by key but never dequeued? I know of many apps that want to have FIFO dequeue behaviour and the ability to be able to replace a message of key if not dequeued or acquired yet. Can this be still be achieved with the new impl? Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997364#comment-12997364 ] Gordon Sim commented on QPID-2104: -- Revision 1069322 adds the desired implementation. The older behaviour is still there for backward compatibility though we should deprecate and remove it eventually. To get the new behaviour you specify the key to use via custom argument 'qpid.last_value_queue_key' (as for Java broker). This is all that is needed to turn on an LVQ. The older arguments without this new key argument will give the legacy behaviour. Note: this implementation does not force all consumers to be browsers (may revisit that decision at some point). > Improved LVQ implementation > --- > > Key: QPID-2104 > URL: https://issues.apache.org/jira/browse/QPID-2104 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.9 > > > My view of what ideal 'LVQ' behaviour would 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. the consumers are always non-competing. > Rob Godfrey also points out that if subscribers fall behind they need only be > sent the latest for every key (i.e. any superceded values can be skipped). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992034#comment-12992034 ] Gordon Sim commented on QPID-2104: -- Patch including this fix available for review: https://reviews.apache.org/r/406/. (That patch includes some refactoring of the queue implementation to make this change possible as well as to cleanup the old LVQ implementation and keep it out of the main codepaths). > Improved LVQ implementation > --- > > Key: QPID-2104 > URL: https://issues.apache.org/jira/browse/QPID-2104 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim > Fix For: 0.9 > > > 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. the consumers are always non-competing. > Rob Godfrey also points out that if subscribers fall behind they need only be > sent the latest for every key (i.e. any superceded values can be skipped). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12797080#action_12797080 ] Gordon Sim commented on QPID-2104: -- The property used as the key should ideally be configurable also. > Improved LVQ implementation > --- > > Key: QPID-2104 > URL: https://issues.apache.org/jira/browse/QPID-2104 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim > > 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. the consumers are always non-competing. > Rob Godfrey also points out that if subscribers fall behind they need only be > sent the latest for every key (i.e. any superceded values can be skipped). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-2104) Improved LVQ implementation
[ https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12755921#action_12755921 ] Gordon Sim commented on QPID-2104: -- >From Andrew Wright: "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." > Improved LVQ implementation > --- > > Key: QPID-2104 > URL: https://issues.apache.org/jira/browse/QPID-2104 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.5 >Reporter: Gordon Sim >Assignee: Gordon Sim > > 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. the consumers are always non-competing. > Rob Godfrey also points out that if subscribers fall behind they need only be > sent the latest for every key (i.e. any superceded values can be skipped). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
