yangwei created ARTEMIS-2418:
--------------------------------

             Summary: Race conditions between cursor movement and page writing
                 Key: ARTEMIS-2418
                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2418
             Project: ActiveMQ Artemis
          Issue Type: Bug
          Components: Broker
    Affects Versions: 2.9.0
            Reporter: yangwei


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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to