[
https://issues.apache.org/jira/browse/HDFS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13582479#comment-13582479
]
Suresh Srinivas commented on HDFS-4222:
---------------------------------------
bq. Nice change. I've quickly scanned the patch and checkSuperuserPrivilege
internally instantiates a permission checker, which appears to be getting
called within the namespace lock in a number of places too.
Good catch.
bq. To reduce the size of the patch, would it maybe make sense to use a
thread-local permission checker singleton? Ie. FsPermissionChecker.init() sets
the thread-local for the current user, and then
FsPermissionChecker.getInstance() instead of new FsPermissionChecker returns
the singleton? Just a thought.
Not sure how to make this work. When does thread local variable get initialized
and when is it cleared, given a thread gets used for different current users?
bq. Another thought might be an option to tell a UGI to "lock-in" it's group
list. Something earlier on at a high level, maybe the NN's RPC server, could
call UserGroupInformation.getCurrentUser().lockGroups().
Not sure I understood this.
> NN is unresponsive and lose heartbeats of DNs when Hadoop is configured to
> use LDAP and LDAP has issues
> -------------------------------------------------------------------------------------------------------
>
> Key: HDFS-4222
> URL: https://issues.apache.org/jira/browse/HDFS-4222
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: namenode
> Affects Versions: 1.0.0, 0.23.3, 2.0.0-alpha
> Reporter: Xiaobo Peng
> Assignee: Xiaobo Peng
> Priority: Minor
> Attachments: hdfs-4222-branch-0.23.3.patch, HDFS-4222.patch,
> hdfs-4222-release-1.0.3.patch
>
>
> For Hadoop clusters configured to access directory information by LDAP, the
> FSNamesystem calls on behave of DFS clients might hang due to LDAP issues
> (including LDAP access issues caused by networking issues) while holding the
> single lock of FSNamesystem. That will result in the NN unresponsive and loss
> of the heartbeats from DNs.
> The places LDAP got accessed by FSNamesystem calls are the instantiation of
> FSPermissionChecker, which could be moved out of the lock scope since the
> instantiation does not need the FSNamesystem lock. After the move, a DFS
> client hang will not affect other threads by hogging the single lock. This is
> especially helpful when we use separate RPC servers for ClientProtocol and
> DatanodeProtocol since the calls for DatanodeProtocol do not need to access
> LDAP. So even if DFS clients hang due to LDAP issues, the NN will still be
> able to process the requests (including heartbeats) from DNs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
