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

        Gordon Sim created issue -
        Gordon Sim made changes -
        Field Original Value New Value
        Fix Version/s 0.9 [ 12315382 ]
        Gordon Sim made changes -
        Description 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).
        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).
        Due Date 2011-02-16 00:00:00.0
        Gordon Sim made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Justin Ross made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          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