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

Suresh Srinivas commented on HDFS-3680:
---------------------------------------

I have not looked at the patch. I will review it later. 

Thinking more about the approach, just removing audit logger on the first 
exception has many issue we need to consider.
# With this approach, should namenode run if for some reason we have removed 
all the audit loggers from the list? My answer would be no, given the 
importance of audit log.
# Does the system need a mechanism to add/remove audit loggers? When a failed 
logger is fixed, do we need a way to refresh the audit logger so it is picked 
up by the Namenode again?
# When you have multiple audit loggers, is there a need to keep them in sync or 
out of sync audit loggers okay?
# Alternatively, should we consider a separate daemon that runs off of the 
audit log written to disk and updates other syncs instead of doing it inline in 
the namenode code?
                
> Allows customized audit logging in HDFS FSNamesystem
> ----------------------------------------------------
>
>                 Key: HDFS-3680
>                 URL: https://issues.apache.org/jira/browse/HDFS-3680
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: name-node
>    Affects Versions: 2.0.0-alpha
>            Reporter: Marcelo Vanzin
>            Assignee: Marcelo Vanzin
>            Priority: Minor
>         Attachments: accesslogger-v1.patch, accesslogger-v2.patch, 
> hdfs-3680-v3.patch, hdfs-3680-v4.patch, hdfs-3680-v5.patch
>
>
> Currently, FSNamesystem writes audit logs to a logger; that makes it easy to 
> get audit logs in some log file. But it makes it kinda tricky to store audit 
> logs in any other way (let's say a database), because it would require the 
> code to implement a log appender (and thus know what logging system is 
> actually being used underneath the façade), and parse the textual log message 
> generated by FSNamesystem.
> I'm attaching a patch that introduces a cleaner interface for this use case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


Reply via email to