hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ramkumar Vadali (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HDFS-1257) Race condition introduced by HADOOP-5124
Date Mon, 22 Nov 2010 21:58:16 GMT

    [ https://issues.apache.org/jira/browse/HDFS-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12934616#action_12934616

Ramkumar Vadali commented on HDFS-1257:

Hi Konstantin, sorry for the delay in getting back to this.

It seems difficult to come up with a general solution to this since some methods in {{BlockManager}}
do fine grained locking with {{namesystem.readLock()/writeLock()}}. In particular, the call
to {{BlockManager.computeReplicationWork}} that you referred to seems safe because of locking
inside {{BlockManager.computeReplicationWorkForBlock()}}.

BlockManager has several calls to {{namesystem.readLock()}} and {{namesystem.writeLock()}}
apart from the one I mention. Are you suggesting a restructuring of those calls?

> Race condition introduced by HADOOP-5124
> ----------------------------------------
>                 Key: HDFS-1257
>                 URL: https://issues.apache.org/jira/browse/HDFS-1257
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: name-node
>            Reporter: Ramkumar Vadali
>         Attachments: HDFS-1257.patch
> HADOOP-5124 provided some improvements to FSNamesystem#recentInvalidateSets. But it introduced
unprotected access to the data structure recentInvalidateSets. Specifically, FSNamesystem.computeInvalidateWork
accesses recentInvalidateSets without read-lock protection. If there is concurrent activity
(like reducing replication on a file) that adds to recentInvalidateSets, the name-node crashes
with a ConcurrentModificationException.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message