Qpid
  1. Qpid
  2. QPID-3527

Messages may not acknowledged immediately after receiving in AUTO_ACKNOWLEDGE mode on 0-10 client

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12
    • Fix Version/s: 0.13
    • Component/s: Java Client
    • Labels:
      None

      Description

      In AUTO_ACKNOWLEDGE mode on 0-10 client messages may not acknowledged immediately after receiving. The message acknowledgement in AA mode is implemented in lazy fashion with flusher thread. As result of it, the acknowledgement might happened in 1 second (by default) after receiving the message.

        Activity

        Hide
        Rajith Attapattu added a comment -

        Actually acknowledgement happens in two ways (based on which ever happens first).

        1. Based on the prefetch (or credit window)
        2. Based on the ack-flusher thread

        First of all, the current behaviour is incorrect as it's the same as DUPS ok.

        The first method was to ack every time the number of unacked messages exceeded more than half the credit window (or prefetch value). I don't know the reasons behind why it was done this way. I am guessing performance.

        The second method was added by myself as I found when there is a large prefetch window, but with very slow message flows, no acks are sent at all. And often when the client fails over all most all messages are replayed. The ack flusher thread prevented that from happening.

        When we fix this issue, we would need to ensure we consider performance. We should also make some noise about this change in the release notes to ensure we don't catch any folks by surprise.

        Show
        Rajith Attapattu added a comment - Actually acknowledgement happens in two ways (based on which ever happens first). 1. Based on the prefetch (or credit window) 2. Based on the ack-flusher thread First of all, the current behaviour is incorrect as it's the same as DUPS ok. The first method was to ack every time the number of unacked messages exceeded more than half the credit window (or prefetch value). I don't know the reasons behind why it was done this way. I am guessing performance. The second method was added by myself as I found when there is a large prefetch window, but with very slow message flows, no acks are sent at all. And often when the client fails over all most all messages are replayed. The ack flusher thread prevented that from happening. When we fix this issue, we would need to ensure we consider performance. We should also make some noise about this change in the release notes to ensure we don't catch any folks by surprise.
        Hide
        Alex Rudyy added a comment -

        Attached patche from Robbie Gemmell and me fixing the issue.

        Show
        Alex Rudyy added a comment - Attached patche from Robbie Gemmell and me fixing the issue.
        Hide
        Alex Rudyy added a comment -

        Robbie, could you please review and apply the patch attached?

        Show
        Alex Rudyy added a comment - Robbie, could you please review and apply the patch attached?
        Hide
        Robbie Gemmell added a comment -

        Patch applied. Auto-ack now results in sending asynchronous acks after each message is delivered to the application.

        Show
        Robbie Gemmell added a comment - Patch applied. Auto-ack now results in sending asynchronous acks after each message is delivered to the application.

          People

          • Assignee:
            Robbie Gemmell
            Reporter:
            Alex Rudyy
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development