[
https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637315#action_12637315
]
Sanjay Radia commented on HADOOP-4044:
--------------------------------------
> Let's not call something 'unclean' just because it is more work.
_It has nothing to do with more work -- I am always willing to do more work for
the right clean solution._
Konstantine also said it is "bizzare" that all the methods return FSLink. I am
not the only one finding this "unclean" or "bizzare".
_There is a the fundamental difference of opinion here:_ severl of us are
arguing that the use of exceptions is fine for recoverable conditions. It
keeps the interface simple and clean.
BTW Do you find such use of exceptions to be acceptable inside the name node?
Both Raghu and I raised this.
Are you suggesting that the namenode side of the code be changed to not use
exceptions?
If so, you are consistent and it will be some work to change the internal name
node code to use FSLink style approach; dhruba's patch does not do this.
If not, why the inconsistency in when exceptions are appropriate or not
appropriate?
>The interfaces should reflect their function.
Having create() return FSLink does not help understand its function.
Return types like "FSLinkBoolean" and FSLinkBlockLocations confuse the function
of the methods in an interface.
The symbolic link issue cuts across all interfaces that have path names.
Overloading the return type of each method that has path name parameters
dilutes how the well the method signature reflects it function.
The method signatures and datatypes are easier to understand if we use
exceptions (which in the opinion of some of us is acceptable for recoverable
conditions).
> Other FSs (e.g., linux VFS) don't try to do this in a single call, but rather
> loop, checking whether each element in the path is a link.
No one is suggesting that we handle it as a single call -- with exceptions it
will loop in exactly the same fashion. Perhaps you have misunderstood the
alternate solution being proposed.
>We can try to hack around that by using exceptions or thread locals or output
>parameters,
> but those are all just attempts to try to make this API look
>like other APIs rather than embrace its differences.
(Q. By overloading the return type aren't you are using output parameters? The
return type is an output parameter.)
Many will consider the overloading of return types also hacky (and this will
get worse when we have other reasons in the future when client side needs to
perform a recovery function.). Clearly we have a difference in opinion on what
is hacky or not.
Comparing to other file systems APIs is not fair here for two reasons:
1) they do not use a programming language that has first class support for
exceptions (both checked and unchecked).
2) Mounts and symbolic links in most systems are handled on the server side
- in most FSs, clients cannot process links.
The only possible exception (no pun intended) is Slash-relative symbolic links
in NFS (I don't know if NFS supports slash-relative symbolic links that are
kicked back to be relative to the client's view of Slash (root)).
In the two approaches being discussed in this Jira, both are looping to process
the operation across links/mount points. The difference is how the
condition is communicated back to caller and the impact it has on the method
signatures and data types used as parameters or return types.
There is a clear difference of opinion here.
I am interpreting your reference URL link differently - I am reading it and
seeing that using exceptions for recovery is acceptable. Further following a
mount point link is *not normal* and hence the use of exception is acceptable.
Joshau's _Effective Java_ also, as per my reading, advocates the use of
checked exceptions for recoverable conditions. You will probably interpret that
text differently or disagree with it.
> Create symbolic links in HDFS
> -----------------------------
>
> Key: HADOOP-4044
> URL: https://issues.apache.org/jira/browse/HADOOP-4044
> Project: Hadoop Core
> Issue Type: New Feature
> Components: dfs
> Reporter: dhruba borthakur
> Assignee: dhruba borthakur
> Attachments: symLink1.patch, symLink1.patch, symLink4.patch,
> symLink5.patch, symLink6.patch, symLink8.patch, symLink9.patch
>
>
> HDFS should support symbolic links. A symbolic link is a special type of file
> that contains a reference to another file or directory in the form of an
> absolute or relative path and that affects pathname resolution. Programs
> which read or write to files named by a symbolic link will behave as if
> operating directly on the target file. However, archiving utilities can
> handle symbolic links specially and manipulate them directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
