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)