hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjay Radia (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-4044) Create symbolic links in HDFS
Date Mon, 06 Oct 2008 18:07:44 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-4044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637158#action_12637158

Sanjay Radia commented on HADOOP-4044:

If throwing a UnresolvedPathException is considered clean style inside the namenode then it
should be clean for RPC interface.
We need to be consistent here. It is either clean style or it s not.

In my opnion, throwing the UnresolvedPathException across the rpc interface is clean -- it
is one of many internal interfaces.

Joshua Bloch in "Effective Java" (item 40) argues that exceptions can be used for recoverable
conditions. The processing the symbolic link is 
a recoverable condition. Later in the same item he argues that such exceptions can provide
information to allow the recovery (in this case the remaining
pathname to resolve).

Indeed the link that Doug gave argues in favour of using declared exceptions for recoverable
_"My rule of thumb for whether I make an exception declared or undeclared is whether localized
recovery from the exception being thrown is sensible. If the calling method (or one of its
recent callers) of the code is the right place to handle a given failure type, I represent
that failure with a declared exception. If, on the other hand, if the failure case is best
handled by a global handler which catches all the exceptions for a given component of a program
and treats them all as failures of that subsystem, I use undeclared exceptions"._ 
In the case of symbolic links, localized recovery by following the symbolic link is possible,
and hence using an exception is acceptable.
Here the author is distinguishing between declared and undeclared -- but the point is that
declared exceptions are okay for recoverable conditions. 

If java did not have the distinction for declared vs undeclared and exceptions were only for
 errors, then Doug's argument would have been valid.

Dhruba made the right choice in throwing the exception inside the name node - otherwise all
the interfaces and code would have become unclean.
The same style should have continued for the RPC operation.

The RPC interfaces in the patch have been changed as follows.

  void create(...) become FSLink create(..)

  and boolean setReplcation()  becomes FSLinkBoolean setReplication(..)
  ... similar for many  other methods.

The original interfaces were intuitive --  the input parameters and the return values are
obvious for each method.
The newer ones have this FSlinkXXX return value that, IMHO, is not clean.
They will get worse with the union overloading overtime if we add new reasons to recover on
the client side.
The use of exceptions would have kept the interface clean (just as was done inside the name
node code).

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

View raw message