jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6888) Flushing the FileStore might return before data is persisted
Date Mon, 06 Nov 2017 08:02:00 GMT

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

Francesco Mari commented on OAK-6888:

The forceful implementation of {{flush}} guarantees better persistence (and thus, in the case
of the standby, visibility) properties than the previous one. As such, it can help to implement
more complex scenarios with higher confidence. Can you outline a scenario where a more flexible
flush policy could be needed?

> Flushing the FileStore might return before data is persisted
> ------------------------------------------------------------
>                 Key: OAK-6888
>                 URL: https://issues.apache.org/jira/browse/OAK-6888
>             Project: Jackrabbit Oak
>          Issue Type: Bug
>          Components: segment-tar
>            Reporter: Francesco Mari
>            Assignee: Francesco Mari
>             Fix For: 1.8, 1.7.11
>         Attachments: failure.txt
> The implementation of {{FileStore#flush}} might return before all the expected data is
persisted on disk. 
> The root cause of this behaviour is the implementation of {{TarRevisions#flush}}, which
is too lenient when acquiring the lock for the journal file. If a background flush operation
is in progress and a user calls {{FileStore#flush}}, that method will immediately return because
the lock of the journal file is already owned by the background flush operation. The caller
doesn't have the guarantee that everything committed before {{FileStore#flush}} is persisted
to disk when the method returns. 
> A fix for this problem might be to create an additional implementation of flush. The
current implementation, needed for the background flush thread, will not be exposed to the
users of {{FileStore}}. The new implementation of {{TarRevisions#flush}} should have stricter
semantics and always guarantee that the persisted head contains everything visible to the
user of {{FileStore}} before the flush operation was started.

This message was sent by Atlassian JIRA

View raw message