hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4979) Implement retry cache on the namenode
Date Sat, 20 Jul 2013 05:52:51 GMT

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

Chris Nauroth commented on HDFS-4979:
-------------------------------------

{code}
    private static boolean useRetryCache() {
      // Do not track non RPC invocation or RPC requests with 
      // invalid callId or clientId in retry cache
      return !Server.isRpcInvocation() || Server.getCallId() < 0
          || Arrays.equals(Server.getClientId(), RpcConstants.DUMMY_CLIENT_ID);
    }
{code}
This method seems to return true when the retry cache is not used, so should the method name
be changed to something like {{skipRetryCache}}?
{code}
      synchronized (mapEntry) {
        while (mapEntry.state == CacheEntry.INPROGRESS) {
          try {
            mapEntry.wait();
          } catch (InterruptedException ie) {
            // Ignored
          }
        }
{code}
Should we restore interrupted status by calling {{Thread.currentThread().interrupt()}} instead
of swallowing the {{InterruptedException}}?  Other unrelated code running on the thread might
depend on seeing the correct interrupted status to work correctly.
{code}
          try {
            deleteInt(src, true); // File exists - delete if overwrite
          } catch (AccessControlException e) {
            logAuditEvent(false, "delete", src);
            throw e;
          }
{code}
Seeing this makes me realize that attempts to overwrite a file by a client with insufficient
permissions causes 2 audit events: once for the delete, and then again for the create, because
{{startFile}} catches the {{AccessControlException}} and logs it again.  It seems like a bug
to log 2 audit events for a single logical operation.  This behavior exists in the current
code, so it's not a new problem introduced in this patch.  Shall I file a separate bug for
this?

                
> Implement retry cache on the namenode
> -------------------------------------
>
>                 Key: HDFS-4979
>                 URL: https://issues.apache.org/jira/browse/HDFS-4979
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: namenode
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>         Attachments: HDFS-4979.1.patch, HDFS-4979.2.patch, HDFS-4979.3.patch, HDFS-4979.4.patch,
HDFS-4979.5.patch, HDFS-4979.6.patch, HDFS-4979.7.patch, HDFS-4979.8.patch, HDFS-4979.9.patch,
HDFS-4979.patch
>
>


--
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

Mime
View raw message