[
https://issues.apache.org/jira/browse/ARTEMIS-2418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic reopened ARTEMIS-2418:
--------------------------------------
> 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
> Priority: Major
> Fix For: 2.10.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> 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
(v8.3.2#803003)
