ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-5772) Race between WAL segment rollover and concurrent log
Date Tue, 18 Jul 2017 12:45:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091505#comment-16091505

ASF GitHub Bot commented on IGNITE-5772:

GitHub user ilantukh opened a pull request:




You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/gridgain/apache-ignite ignite-5772

Alternatively you can review and apply these changes as the patch at:


To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #2313
commit b12ffd16a18150fadf85442b443d576edc205f10
Author: Ilya Lantukh <ilantukh@gridgain.com>
Date:   2017-07-18T12:16:29Z

    ignite-5772: WAL redesign - stop flag in FakeRecord.

commit 63451b67b4763ea93e650785d6fefa289d5571eb
Author: Ilya Lantukh <ilantukh@gridgain.com>
Date:   2017-07-18T12:43:41Z

    ignite-5772: WAL redesign - stop flag in FakeRecord.


> Race between WAL segment rollover and concurrent log
> ----------------------------------------------------
>                 Key: IGNITE-5772
>                 URL: https://issues.apache.org/jira/browse/IGNITE-5772
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: 2.1
>            Reporter: Alexey Goncharuk
>            Assignee: Ilya Lantukh
>             Fix For: 2.2
> The WAL log() and close() are synch-ed as follows:
> log: read head, check stop flag, cas head
> close: set stop flag, cas head to fake record.
> This guarantees that after close() is called, there will be no other records appended
to the closed segment.
> Now consider three threads doing the following operations:
> T1: flush(); T2: rollOver(); T3: log();
> The sequence of events:
> 1) T1 does a CAS of head to FakeRecord
> 2) T3 reads head as FakeRecord, reads stop flag as false
> 3) T2 attempts to rollOver: CAS stop to true; call flushOrWait(null); call flush(null);
Since the head is an instance of FakeRecord, the flush(null) immediately returns false. This
thread waits for written bytes and proceeds
> 4) T3 successfully does a CAS of head to non-fake record
> 5) T2 proceeds with rollOver, signals next available and asserts on head.
> The invariant above is broken when T2 does not CAS fake record during rollover, which
allows T3 to append an entry to the closed segment. The solution is to change the code so
the CAS is always attempted on close even if the current head is already a FakeRecord.
> Alternatively, we can introduce another type of fake record that will seal the WAL segment

This message was sent by Atlassian JIRA

View raw message