[jira] [Created] (IGNITE-13137) WAL reservation may failed even though the required segment is available

["Vyacheslav Koptilin (Jira)" <ji...@apache.org>]

Vyacheslav Koptilin created IGNITE-13137:
--------------------------------------------

             Summary: WAL reservation may failed even though the required segment is available
                 Key: IGNITE-13137
                 URL: https://issues.apache.org/jira/browse/IGNITE-13137
             Project: Ignite
          Issue Type: Bug
          Components: persistence
    Affects Versions: 2.8
            Reporter: Vyacheslav Koptilin


It seems there is a race in {{FileWriteAheadLogManager}} that may lead to the inability to reserve a WAL segment. 
Let's consider the following scenario:
 - log WAL record that requires a rollover of the current segment.
 - archiver is moving the WAL file to an archive folder
 - trying to reserve this segment


{code:java}
@Override public boolean reserve(WALPointer start) {
    ...
    segmentAware.reserve(((FileWALPointer)start).index());

    if (!hasIndex(((FileWALPointer)start).index())) {          <-- hasIndex returns false
        segmentAware.release(((FileWALPointer)start).index());

        return false;
    }
    ...
}

private boolean hasIndex(long absIdx) {
    ...
    boolean inArchive = new File(walArchiveDir, segmentName).exists() ||
        new File(walArchiveDir, zipSegmentName).exists();

    if (inArchive)    <-- At this point, the required WAL segment is not moved yet, so inArchive == false
        return true;

    if (absIdx <= lastArchivedIndex()) <-- lastArchivedIndex() scans archive directory and finds a new WAL segment, and absIdx == lastArchivedIndex!
        return false;

    FileWriteHandle cur = currHnd;

    return cur != null && cur.getSegmentId() >= absIdx;
}

{code}

Besides this race, it seems to me, the behavior of WAL reservation should be improved in a case when the required segment is already reserved/locked. In that particular case, we don't need to check WAL archive directory at all.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)