[ https://issues.apache.org/jira/browse/HDFS-6422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charles Lamb updated HDFS-6422: ------------------------------- Attachment: HDFS-6422.007.patch bq. logAuditEvent(false, "getXAttr", src); --> logAuditEvent(false, "getXAttrs", src); fixed. {code} } else { + throw new IOException("No matching attributes found"); {code} Changed to "No matching attributes found for remove operation" bq. And this condition makes me to think on retryCache. I hope it is done here let me see there. Example first call may succeed internally but restarted/disconnected, in that case idempotent API will be retried from client. So, next call may fail as it was already removed. Do you think, we need to mark this as ATMostOnce? Good catch. You're right that my changes require removeXAttr to become AtMostOnce. I've changed the code to reflect that. bq. I think below exception message can be refined something like "Some/all attributes does not match to get"? I've chnages this to "At least one of the attributes provided was not found." TestDFSShell.java: bq. From the below code, we don't need out.toString as we did not asserted anything. removed. bq. We need to shutdown the mini cluster as well. Done. FSXAttrBaseTest.java: bq. Please handle only specific exceptions. If it throws unexpected exception let it throwout, we need not assert and throw. All of this is due to WebHDFS throwing a different exception from the regular path. WebHDFS throws a RemoteException which wraps a HadoopIllegalArgumentException. In other words, the WebHDFS client does not unwrap the exception. You'll see in the diff that I've changed the exception handling to catch both RemoteException and HadoopIllegalArgumentException. In the former case, I check to see that the underlying exception is a HIAE. XattrNameParam.java: {code} private static Domain DOMAIN = new Domain(NAME, + Pattern.compile(".*")); {code} bq. I understand that we try to eliminate the client validation as we will not have flexibility to add more namespaces in future. But that pattern can be same as <Namespace>. right. So, how about validating pattern? Please check with Andrew as well what he says. But I have no strong feeling on that. It is a suggestion. I understand your concern. The problem is that WebHDFS would then be doing client side checking and the exception would be generated and thrown from two different places. We wanted to unify all of the xattr Namespace checking into one place on the server side so that there would only be one place where the exception would be generated. I talked to Andrew and he's ok with leaving it like it is in the patch. > getfattr in CLI doesn't throw exception or return non-0 return code when > xattr doesn't exist > -------------------------------------------------------------------------------------------- > > Key: HDFS-6422 > URL: https://issues.apache.org/jira/browse/HDFS-6422 > Project: Hadoop HDFS > Issue Type: Bug > Affects Versions: 3.0.0, 2.5.0 > Reporter: Charles Lamb > Assignee: Charles Lamb > Priority: Blocker > Attachments: HDFS-6422.005.patch, HDFS-6422.006.patch, > HDFS-6422.007.patch, HDFS-6422.1.patch, HDFS-6422.2.patch, HDFS-6422.3.patch, > HDFS-6474.4.patch > > > If you do > hdfs dfs -getfattr -n user.blah /foo > and user.blah doesn't exist, the command prints > # file: /foo > and a 0 return code. > It should print an exception and return a non-0 return code instead. -- This message was sent by Atlassian JIRA (v6.2#6252)