Uploaded image for project: 'ActiveMQ Artemis'
  1. ActiveMQ Artemis
  2. ARTEMIS-2418

Race conditions between cursor movement and page writing

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.9.0
    • 2.10.0
    • Broker
    • None

    Description

      The current code of CursorIterator::internalGetNext is a little complicated and not easy to follow logically.

      And there are two race conditions between cursor movement and page writing:

      1. Suppose the cursor's initial position is (p1,0) and page p1 is live with 0 msg. When we call internalGetNext(), the cursor moves to next page, i.e. position is (p2, 0) now. Meanwhile p1 is filled with message m1 and p2 is created with m2. Then we retrieve m2 from p2 rather than m1.

      2. Suppose the cursor's initial position is (p1, 1) and the page p1 is non live with 1 msg. When we call  internalGetNext(), the cursor moves to position(p2, 0) and get null page cache since p2 is not yet created. Then p2 is created with m1 and p3 is created with m2 which means current writing page no. is p3. After the while loop the cursor moves to position(p3, 0) and we retrieve m2 from p3 rather than m1.

      In both cases we would miss message m1 and subsequent page files won't be deleted unless the broker restarts.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              wy96f Wei Yang
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 1h 10m
                  1h 10m