Details

    • Type: Feature Request Feature Request
    • Status: 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.

        Gliffy Diagrams

          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: