Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: core-dev@hadoop.apache.org
Message-ID: <1843419665.1223338004390.JavaMail.jira@brutus>
Date: Mon, 6 Oct 2008 17:06:44 -0700 (PDT)
From: "Sanjay Radia (JIRA)" <jira@apache.org>
To: core-dev@hadoop.apache.org
Subject: [jira] Commented: (HADOOP-4044) Create symbolic links in HDFS
In-Reply-To: <132525105.1219991324428.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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