Details

    • Type: Feature Request Feature Request
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 5.5.0-fuse-00-53
    • Fix Version/s: 5.5.1-fuse-01-06
    • Component/s: broker
    • Labels:
      None
    • Similar Issues:
      Show 9 results 

      Description

      For a consumer to fully rely on the JMSRedelivered flag, the broker needs to persist this flag whenever it changes into its persistence store.

        Issue Links

          Activity

          Hide
          Gary Tully
          added a comment -

          Thinking on this a bit, the delivery flag needs to be treated like a message ack.

          Currently the broker becomes aware of redelivery when a consumer closes and provides the broker sequence id of the last message delivered to the consumer. Any inflight messages with id > that that sequence are deemed to be redelivered.
          In the even of a consumer failure, the close info from the consumer is lost, all unconsumed are deemed redelivered and there can be false positives.
          In the event of a broker failure, all redelivery information is lost.

          The change would have the consumer send an delivered_ack before a message is consumed, this would be a sync call that would require the broker to sync to disk. This will be as costly as a transaction commit!
          There is a chance of a false positive on the redelivered flag, if the consumer fails after the delivered ack is persisted by the broker but before delivery of a message.

          It may not be necessary to track updates in the index, in the event of failure we could always rebuild the index if this feature is enabled as it will be a rare event.

          Question: is fast recovery vital in this case?

          Show
          Gary Tully
          added a comment - Thinking on this a bit, the delivery flag needs to be treated like a message ack. Currently the broker becomes aware of redelivery when a consumer closes and provides the broker sequence id of the last message delivered to the consumer. Any inflight messages with id > that that sequence are deemed to be redelivered. In the even of a consumer failure, the close info from the consumer is lost, all unconsumed are deemed redelivered and there can be false positives. In the event of a broker failure, all redelivery information is lost. The change would have the consumer send an delivered_ack before a message is consumed, this would be a sync call that would require the broker to sync to disk. This will be as costly as a transaction commit! There is a chance of a false positive on the redelivered flag, if the consumer fails after the delivered ack is persisted by the broker but before delivery of a message. It may not be necessary to track updates in the index, in the event of failure we could always rebuild the index if this feature is enabled as it will be a rare event. Question: is fast recovery vital in this case?
          Hide
          Gary Tully
          added a comment -
          Show
          Gary Tully
          added a comment - Add link to issue at apache: https://issues.apache.org/jira/browse/AMQ-3519
          Hide
          Gary Tully
          added a comment -

          merging to 5.5.1 branch

          Show
          Gary Tully
          added a comment - merging to 5.5.1 branch

            People

            • Assignee:
              Gary Tully
              Reporter:
              Torsten Mielke
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: