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