[ https://issues.apache.org/jira/browse/HDFS-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13990882#comment-13990882 ]
Daryn Sharp commented on HDFS-6326: ----------------------------------- Catching all exceptions bothers me a bit that if the call fails for other transient errors, that acls are assumed to not be supported. Maybe it doesn't seem like a big deal today because it's "only" for one command, but it will be if I ever get around to adding readline support to FsShell... It's probably more appropriate for WebHdfsFileSystem to detect if acls are supported upon the first call. It keeps the ugliness out of FsShell. It would be great to also push the hdfs-specific exception handling into DistributedFileSystem. Given that we now have extensible protobufs and json, is there any reason why FileStatus, or FSPermission, etc don't return a boolean if there's an acl on the file? Then an acl call is may only be made when necessary. The performance impact of doubling the rpc/webhdfs calls for ls concerns me, especially for recursive ls on a large directory, when acls are likely to be the exception rather than the common case. > WebHdfs ACL compatibility is broken > ----------------------------------- > > Key: HDFS-6326 > URL: https://issues.apache.org/jira/browse/HDFS-6326 > Project: Hadoop HDFS > Issue Type: Bug > Components: webhdfs > Affects Versions: 3.0.0, 2.4.0 > Reporter: Daryn Sharp > Assignee: Chris Nauroth > Priority: Blocker > Attachments: HDFS-6326.1.patch, HDFS-6326.2.patch > > > 2.4 ACL support is completely incompatible with <2.4 webhdfs servers. The NN > throws an {{IllegalArgumentException}} exception. > {code} > hadoop fs -ls webhdfs://nn/ > Found 21 items > ls: Invalid value for webhdfs parameter "op": No enum constant > org.apache.hadoop.hdfs.web.resources.GetOpParam.Op.GETACLSTATUS > [... 20 more times...] > {code} -- This message was sent by Atlassian JIRA (v6.2#6252)