[
https://issues.apache.org/jira/browse/HDFS-11246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093843#comment-16093843
]
Daryn Sharp commented on HDFS-11246:
------------------------------------
I'm not sure I like either of the the suggestions because it re-orders the
audit logging and edit log syncing. On a semantic level, one might expect the
audit log to only include durable edits. It may be confusing to see audits for
edits lost in a crash.
More importantly logging before syncing is likely to increase the odds of less
txns batched per sync. Log4j synchronization can be a real bottleneck, even
with the async appender support I added.
The double try feels a bit odd but it seems like a clean change that doesn't
cause edit/audit reordering.
> 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
>
>
> {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]
