[
https://issues.apache.org/jira/browse/HDFS-11246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16268923#comment-16268923
]
Daryn Sharp commented on HDFS-11246:
------------------------------------
Coming back to this patch, had a recent incident with user flooding ops
generating ACE in the lock.
In my earlier comment, I meant the pattern used to be "lock - try - finally
unlock". The prior patches used "lock - try - try", whereas I wanted "try -
lock - try" to match the prior pattern, not "try - try - lock" in the latest
patch. This very important in the event the locking call fails because the
inner finally will cause an unbalanced unlock. The fsn lock is no longer
trivial and could be prone to a runtime exception or OOM, hence the resource
(lock) should be acquired outside the inner try.
> FSNameSystem#logAuditEvent should be called outside the read or write locks
> ---------------------------------------------------------------------------
>
> Key: HDFS-11246
> URL: https://issues.apache.org/jira/browse/HDFS-11246
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.7.3
> Reporter: Kuhu Shukla
> Assignee: Kuhu Shukla
> Attachments: HDFS-11246.001.patch, HDFS-11246.002.patch,
> HDFS-11246.003.patch, HDFS-11246.004.patch
>
>
> {code}
> readLock();
> boolean success = true;
> ContentSummary cs;
> try {
> checkOperation(OperationCategory.READ);
> cs = FSDirStatAndListingOp.getContentSummary(dir, src);
> } catch (AccessControlException ace) {
> success = false;
> logAuditEvent(success, operationName, src);
> throw ace;
> } finally {
> readUnlock(operationName);
> }
> {code}
> It would be nice to have audit logging outside the lock esp. in scenarios
> where applications hammer a given operation several times.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
