Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.9
    • Component/s: C++ Broker
    • Labels:
      None

      Description

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

        Activity

        Hide
        Gordon Sim added a comment -

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

        Show
        Gordon Sim added a comment - 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."
        Hide
        Gordon Sim added a comment -

        The property used as the key should ideally be configurable also.

        Show
        Gordon Sim added a comment - The property used as the key should ideally be configurable also.
        Hide
        Gordon Sim added a comment -

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

        Show
        Gordon Sim added a comment - 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).
        Hide
        Gordon Sim added a comment -

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

        Show
        Gordon Sim added a comment - 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).

          People

          • Assignee:
            Gordon Sim
            Reporter:
            Gordon Sim
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Development