[
https://issues.apache.org/jira/browse/HDFS-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated HDFS-1597:
------------------------------
Description:
The top of FSEditLog.logSync has the following assertion:
{code}
assert editStreams.size() > 0 : "no editlog streams";
{code}
which should actually come after checking to see if the sync was already
batched in by another thread.
This is related to a second bug in which the same case causes synctxid to be
reset to 0
was:
The top of FSEditLog.logSync has the following assertion:
{code}
assert editStreams.size() > 0 : "no editlog streams";
{code}
which should actually come after checking to see if the sync was already
batched in by another thread.
Will describe the race in a comment.
Summary: Batched edit log syncs can reset synctxid throw assertions
(was: Misplaced assertion in FSEditLog.logSync)
Updated description to reflect the other problem as well
> Batched edit log syncs can reset synctxid throw assertions
> ----------------------------------------------------------
>
> Key: HDFS-1597
> URL: https://issues.apache.org/jira/browse/HDFS-1597
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 0.22.0
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Fix For: 0.22.0
>
> Attachments: illustrate-test-failure.txt
>
>
> The top of FSEditLog.logSync has the following assertion:
> {code}
> assert editStreams.size() > 0 : "no editlog streams";
> {code}
> which should actually come after checking to see if the sync was already
> batched in by another thread.
> This is related to a second bug in which the same case causes synctxid to be
> reset to 0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
