You are viewing a plain text version of this content. The canonical link for it is here.
Posted to hdfs-issues@hadoop.apache.org by "Todd Lipcon (JIRA)" <ji...@apache.org> on 2011/01/26 02:04:43 UTC

[jira] Updated: (HDFS-1597) Batched edit log syncs can reset synctxid throw assertions

     [ 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.