Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-2450

Only complete hostname is supported to access data via hdfs://

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.20.205.0
    • Fix Version/s: 1.0.0
    • Component/s: None
    • Labels:
      None
    • Target Version/s:

      Description

      If my complete hostname is host1.abc.xyz.com, only complete hostname must be used to access data via hdfs://

      I am running following in .20.205 Client to get data from .20.205 NN (host1)
      $hadoop dfs -copyFromLocal /etc/passwd hdfs://host1/tmp
      copyFromLocal: Wrong FS: hdfs://host1/tmp, expected: hdfs://host1.abc.xyz.com
      Usage: java FsShell [-copyFromLocal <localsrc> ... <dst>]

      $hadoop dfs -copyFromLocal /etc/passwd hdfs://host1.abc/tmp/
      copyFromLocal: Wrong FS: hdfs://host1.blue/tmp/1, expected: hdfs://host1.abc.xyz.com
      Usage: java FsShell [-copyFromLocal <localsrc> ... <dst>]

      $hadoop dfs -copyFromLocal /etc/passwd hftp://host1.abc.xyz/tmp/
      copyFromLocal: Wrong FS: hdfs://host1.blue/tmp/1, expected: hdfs://host1.abc.xyz.com
      Usage: java FsShell [-copyFromLocal <localsrc> ... <dst>]

      Only following is supported
      $hadoop dfs -copyFromLocal /etc/passwd hdfs://host1.abc.xyz.com/tmp/

      1. HDFS-2450-5.patch
        30 kB
        Daryn Sharp
      2. HDFS-2450-4.patch
        29 kB
        Daryn Sharp
      3. HDFS-2450-3.patch
        23 kB
        Daryn Sharp
      4. HDFS-2450-2.patch
        11 kB
        Daryn Sharp
      5. IP vs. Hostname.pdf
        98 kB
        Daryn Sharp
      6. HDFS-2450-1.patch
        10 kB
        Daryn Sharp
      7. HDFS-2450.patch
        14 kB
        Daryn Sharp

        Issue Links

          Activity

          Hide
          Rajit Saha added a comment -

          This happens only with
          hadoop.security.token.service.use_ip = false in core-site.xml in client side

          Show
          Rajit Saha added a comment - This happens only with hadoop.security.token.service.use_ip = false in core-site.xml in client side
          Hide
          Daryn Sharp added a comment -

          The exception originates in FileSystem.checkPath() which is used to see if a Path belongs to the FileSystem. Among other things, it does a simple string comparisons of the host in the uri's authority. There is an interaction when setting use_ip=false to enable the use of host-based tokens. The NetUtils methods to create an InetSocketAddress will return FQDNs to increase the security of host-based tokens. With a FQDN, there is no ambiguity, regardless of the host's dns search path.

          The observed issue is that DistributedFileSystem does not store its designated uri as-is. Instead it takes the uri's authority, converts it to a InetSocketAddress, and then converts it back to a string. With use_ip=true, the default behavior, the conversion are unnecessary but always yield the original value. With use_ip=false, the host will become a FQDN after the conversions, so simple string comparison between the FQDN and short hostname fails...

          Show
          Daryn Sharp added a comment - The exception originates in FileSystem.checkPath() which is used to see if a Path belongs to the FileSystem . Among other things, it does a simple string comparisons of the host in the uri's authority. There is an interaction when setting use_ip=false to enable the use of host-based tokens. The NetUtils methods to create an InetSocketAddress will return FQDNs to increase the security of host-based tokens. With a FQDN, there is no ambiguity, regardless of the host's dns search path. The observed issue is that DistributedFileSystem does not store its designated uri as-is. Instead it takes the uri's authority, converts it to a InetSocketAddress , and then converts it back to a string. With use_ip=true, the default behavior, the conversion are unnecessary but always yield the original value. With use_ip=false, the host will become a FQDN after the conversions, so simple string comparison between the FQDN and short hostname fails...
          Hide
          Daryn Sharp added a comment -

          I added more definite checks to FileSystem.checkPath(Path) to properly detect equivalence between long and short hostnames.

          Tweak DistributedFileSystem to stop unnecessarily mangling the given URIs which led to the problem being noticed. This should prevent the DFS from not realizing it owns its paths, and not make the aforementioned checkPath changes have to work very hard.

          Commit tests passed, will post full test results tomorrow morning.

          Show
          Daryn Sharp added a comment - I added more definite checks to FileSystem.checkPath(Path) to properly detect equivalence between long and short hostnames. Tweak DistributedFileSystem to stop unnecessarily mangling the given URIs which led to the problem being noticed. This should prevent the DFS from not realizing it owns its paths, and not make the aforementioned checkPath changes have to work very hard. Commit tests passed, will post full test results tomorrow morning.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12499612/HDFS-2450.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1389//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12499612/HDFS-2450.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1389//console This message is automatically generated.
          Hide
          Daryn Sharp added a comment -

          [exec] +1 overall.
          [exec]
          [exec] +1 @author. The patch does not contain any @author tags.
          [exec]
          [exec] +1 tests included. The patch appears to include 3 new or modified tests.
          [exec]
          [exec] +1 javadoc. The javadoc tool did not generate any warning messages.
          [exec]
          [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
          [exec]
          [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          Show
          Daryn Sharp added a comment - [exec] +1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
          Hide
          Daryn Sharp added a comment -

          Trimmed out as much as I could, reverted the refactor of checkPath, and removed extraneous comments based on input from Suresh & Nicholas.

          Show
          Daryn Sharp added a comment - Trimmed out as much as I could, reverted the refactor of checkPath , and removed extraneous comments based on input from Suresh & Nicholas.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12499910/HDFS-2450-1.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1399//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12499910/HDFS-2450-1.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1399//console This message is automatically generated.
          Hide
          Suresh Srinivas added a comment -
          1. FileSystem.java
            • Please cache canonical URI for defaultURI and FileSystem URI, instead of getting it call to checkPath.
            • Please add more details to getCanonicalUri() method as to what is expected in uri's hostname (FQDN).
            • Code duplication in the following snippet can be avoided by creating a protected static method.
              +        if (thisScheme.equalsIgnoreCase(defaultUri.getScheme())) {
              +          if (thisAuthority.equalsIgnoreCase(defaultUri.getAuthority()))
              +            return;
              +          defaultUri = NetUtils.getCanonicalUri(defaultUri, getDefaultPort());
              +          thisAuthority = getCanonicalUri().getAuthority();
              +          if (thisAuthority.equalsIgnoreCase(defaultUri.getAuthority()))
              +            return;
              
          2. DistributedFileSystem.java - The existing methods checkPath() and makeQualified() allowed default ports exclusively (indicated in the javadoc). I am not sure why that was done. Why is this patch removing that?
          3. In tests how does host become host.a.b?
          Show
          Suresh Srinivas added a comment - FileSystem.java Please cache canonical URI for defaultURI and FileSystem URI, instead of getting it call to checkPath. Please add more details to getCanonicalUri() method as to what is expected in uri's hostname (FQDN). Code duplication in the following snippet can be avoided by creating a protected static method. + if (thisScheme.equalsIgnoreCase(defaultUri.getScheme())) { + if (thisAuthority.equalsIgnoreCase(defaultUri.getAuthority())) + return; + defaultUri = NetUtils.getCanonicalUri(defaultUri, getDefaultPort()); + thisAuthority = getCanonicalUri().getAuthority(); + if (thisAuthority.equalsIgnoreCase(defaultUri.getAuthority())) + return; DistributedFileSystem.java - The existing methods checkPath() and makeQualified() allowed default ports exclusively (indicated in the javadoc). I am not sure why that was done. Why is this patch removing that? In tests how does host become host.a.b?
          Hide
          Daryn Sharp added a comment -

          Attaching a doc to clarify how this jira and 7510 interact. Will revise patch and repost per comments.

          Show
          Daryn Sharp added a comment - Attaching a doc to clarify how this jira and 7510 interact. Will revise patch and repost per comments.
          Hide
          Daryn Sharp added a comment -

          Optimized NetUtils.getCanonicalUri() to return same uri in majority of cases. DNS canonical resolutions are cached to accelerate the method when use_ip=false.

          Optimized FileSystem.checkPath() to avoid redundant code. I tried to keep it as similar as possible to simplify review. Although I was itching to change it to stop creating locals that won't be used in some cases, or that will be used only once, etc.

          DistributedFileSystem manages its uri like the other filesystems. By not manipulating the given uri, the removed methods are not needed to compensate for the previous manipulations.

          Tests appear to be passing. Running full test suite overnight.

          Show
          Daryn Sharp added a comment - Optimized NetUtils.getCanonicalUri() to return same uri in majority of cases. DNS canonical resolutions are cached to accelerate the method when use_ip=false. Optimized FileSystem.checkPath() to avoid redundant code. I tried to keep it as similar as possible to simplify review. Although I was itching to change it to stop creating locals that won't be used in some cases, or that will be used only once, etc. DistributedFileSystem manages its uri like the other filesystems. By not manipulating the given uri, the removed methods are not needed to compensate for the previous manipulations. Tests appear to be passing. Running full test suite overnight.
          Hide
          Robert Joseph Evans added a comment -

          I am not an expert in HDFS, but I have read through the changes and they look good to me. Only one new public API was added NetUtils.getCanonicalUri, which has tests for it. I am not positive how DistibutedFileSystem's uri is used in all cases, but from what I have read so far it looks OK to not to the port modifications that it was doing previous to this patch.

          Show
          Robert Joseph Evans added a comment - I am not an expert in HDFS, but I have read through the changes and they look good to me. Only one new public API was added NetUtils.getCanonicalUri, which has tests for it. I am not positive how DistibutedFileSystem's uri is used in all cases, but from what I have read so far it looks OK to not to the port modifications that it was doing previous to this patch.
          Hide
          Daryn Sharp added a comment -

          Full test suite passes.

          [exec] +1 overall.
          [exec]
          [exec] +1 @author. The patch does not contain any @author tags.
          [exec]
          [exec] +1 tests included. The patch appears to include 3 new or modified tests.
          [exec]
          [exec] +1 javadoc. The javadoc tool did not generate any warning messages.
          [exec]
          [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
          [exec]
          [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.

          Show
          Daryn Sharp added a comment - Full test suite passes. [exec] +1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings.
          Hide
          Suresh Srinivas added a comment -

          Comments:

          1. FileSystem#checkPath
            • Unrelated this patch - can you get thatScheme before making if (uri.getScheme() == null check. This avoids getting scheme twice from the URI.
            • Earlier the check was based on thisAuthority using the port that the file system had. Now it with getCanonicalUri(), it uses default port. Is this correct? All checks seem to be using defaultPort.
            • Why remove?
                    if (thisAuthority == thatAuthority ||       // & authorities match
                        (thisAuthority != null && 
                         thisAuthority.equalsIgnoreCase(thatAuthority)))
                      return;
              
                       try {                                     // or the default fs's uri
                        defaultUri = get(getConf()).getUri();
                      } catch (IOException e) {
                        throw new RuntimeException(e);
                      }
              
            • The new method does not work for some cases like the previous one. If thisAuthority and thatAuthority is null, the new mehod throw IllegalArgumentException. This is due to removing an if condition after scheme check.
            • If thisAuthority and thatAuthority are not null, you end up parsing the URI for thatAuthority twice. This is due to removing an if condition after scheme check.
          2. DistributedFileSystem#makeQualified remove makes me concerned. I have not gone through all the cases to make sure there is no problem with that change.

          Can you please describe tests you run?

          Show
          Suresh Srinivas added a comment - Comments: FileSystem#checkPath Unrelated this patch - can you get thatScheme before making if (uri.getScheme() == null check. This avoids getting scheme twice from the URI. Earlier the check was based on thisAuthority using the port that the file system had. Now it with getCanonicalUri(), it uses default port. Is this correct? All checks seem to be using defaultPort. Why remove? if (thisAuthority == thatAuthority || // & authorities match (thisAuthority != null && thisAuthority.equalsIgnoreCase(thatAuthority))) return; try { // or the default fs's uri defaultUri = get(getConf()).getUri(); } catch (IOException e) { throw new RuntimeException(e); } The new method does not work for some cases like the previous one. If thisAuthority and thatAuthority is null, the new mehod throw IllegalArgumentException. This is due to removing an if condition after scheme check. If thisAuthority and thatAuthority are not null, you end up parsing the URI for thatAuthority twice. This is due to removing an if condition after scheme check. DistributedFileSystem#makeQualified remove makes me concerned. I have not gone through all the cases to make sure there is no problem with that change. Can you please describe tests you run?
          Hide
          Daryn Sharp added a comment -
          1. "can you get thatScheme before making if ..."
            • Gladly! That was one of the aforementioned things I was "itching" to do, but removed before posting the patch to minimize the change.
          2. "All checks seem to be using defaultPort"
            • No, the default port is only used if there is not a port in the uri
          3. "Why remove?"
            • Default uri is sufficient because FileSystem.get(defaultUri, conf).getUri() equals defaultUri. Also note about instantiating the default fs:
              1. It's relatively expensive, and horrifically bad if the fs cache is disabled to create a new fs
              2. If the default fs is down, the thread blocks while rpc retries occur
              3. The thrown RuntimeException is likely blow up the client, as opposed to the IllegalArgumentException the caller expects.
          4. "If thisAuthority and thatAuthority is null, the new mehod throw IllegalArgumentException"
            • No, the == on the authorities will catch this case.
          5. "If thisAuthority and thatAuthority are not null, you end up parsing the URI for thatAuthority twice."
            • Yes, once before canonicalization, once after canonicalization.
          6. "DistributedFileSystem#makeQualified remove makes me concerned"
            • The only reason it existed is because NameNode.getUri() was stripping off the default port. This alone would cause p = new Path("hdfs://host:default-port/file"); fs = p.getFileSystem(conf) to be incompatible because the path has a port, but the fs stripped it off. So an override of checkPath and makeQualified were added to strip the default port from paths too. All of it is completely unnecessary, especially with canonicalization.

          Tests:

          1. full test suite
          2. manual testing with FsShell "ls":
            • scheme://short
            • scheme://short:port
            • scheme://short.partial
            • scheme://short.partial:port
            • scheme://fqdn
            • scheme://fqdn:port
            • scheme://ip
            • scheme://ip:port
          3. adding more unit tests to automate stressing checkPath via DFS, both positive and negative cases
          Show
          Daryn Sharp added a comment - "can you get thatScheme before making if ..." Gladly! That was one of the aforementioned things I was "itching" to do, but removed before posting the patch to minimize the change. "All checks seem to be using defaultPort" No, the default port is only used if there is not a port in the uri "Why remove?" Default uri is sufficient because FileSystem.get(defaultUri, conf).getUri() equals defaultUri . Also note about instantiating the default fs: It's relatively expensive, and horrifically bad if the fs cache is disabled to create a new fs If the default fs is down, the thread blocks while rpc retries occur The thrown RuntimeException is likely blow up the client, as opposed to the IllegalArgumentException the caller expects. "If thisAuthority and thatAuthority is null, the new mehod throw IllegalArgumentException" No, the == on the authorities will catch this case. "If thisAuthority and thatAuthority are not null, you end up parsing the URI for thatAuthority twice." Yes, once before canonicalization, once after canonicalization. "DistributedFileSystem#makeQualified remove makes me concerned" The only reason it existed is because NameNode.getUri() was stripping off the default port. This alone would cause p = new Path("hdfs://host:default-port/file"); fs = p.getFileSystem(conf) to be incompatible because the path has a port, but the fs stripped it off. So an override of checkPath and makeQualified were added to strip the default port from paths too. All of it is completely unnecessary, especially with canonicalization. Tests: full test suite manual testing with FsShell "ls": scheme://short scheme://short:port scheme://short.partial scheme://short.partial:port scheme://fqdn scheme://fqdn:port scheme://ip scheme://ip:port adding more unit tests to automate stressing checkPath via DFS , both positive and negative cases
          Hide
          Daryn Sharp added a comment -

          Moved assignment of temporaries per Suresh. Added an exhaustive set of tests.

          Show
          Daryn Sharp added a comment - Moved assignment of temporaries per Suresh. Added an exhaustive set of tests.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12500997/HDFS-2450-3.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 3 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1470//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12500997/HDFS-2450-3.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1470//console This message is automatically generated.
          Hide
          Suresh Srinivas added a comment -

          Patch looks good. Some minor comments:

          1. Should the tests added in TestNetUtils for FileSystem#checkPath be moved to TestFileSystem?
          2. FileSytem#getCanonicalUri() is now a public method. Is this done for test purpose only or do you intend it to be a public API? If it is the former, then you could make it protected and addressing previous comment would allow calling it from TestFileSystem.
          Show
          Suresh Srinivas added a comment - Patch looks good. Some minor comments: Should the tests added in TestNetUtils for FileSystem#checkPath be moved to TestFileSystem? FileSytem#getCanonicalUri() is now a public method. Is this done for test purpose only or do you intend it to be a public API? If it is the former, then you could make it protected and addressing previous comment would allow calling it from TestFileSystem.
          Hide
          Daryn Sharp added a comment -

          Thanks for the review comments, Suresh!

          1. I see your point. I had originally thought about adding them there, but reconsidered for the following reasons. If you have a strong preference, I will try to move the tests to TestFileSystem.
            • I would have to copy-n-paste the test resolver into TestFileSystem
            • I couldn't use the test resolver from TestFileSystem w/o increasing the visibility of NetUtils methods to control the resolver – which I don't think either of us would like to be publicly visible.
            • While the FileSystem related tests are exercising the ability of checkPath(...) to compare canonicals, it also exercising the canonicalizing code in NetUtils. I admit it's a tenuous connection.
          2. I contemplated whether getCanonicalUri() should be public. My final decision was influenced by testability, but the main reason is I realized that external callers cannot directly use NetUtils.getCanonicalUri(...) since FileSystem#getDefaultPort() is a protected method. It seems natural to publicly expose getUri() and getCanonicalUri(), but if you disagree, I will try to change it.
          Show
          Daryn Sharp added a comment - Thanks for the review comments, Suresh! I see your point. I had originally thought about adding them there, but reconsidered for the following reasons. If you have a strong preference, I will try to move the tests to TestFileSystem . I would have to copy-n-paste the test resolver into TestFileSystem I couldn't use the test resolver from TestFileSystem w/o increasing the visibility of NetUtils methods to control the resolver – which I don't think either of us would like to be publicly visible. While the FileSystem related tests are exercising the ability of checkPath(...) to compare canonicals, it also exercising the canonicalizing code in NetUtils . I admit it's a tenuous connection. I contemplated whether getCanonicalUri() should be public. My final decision was influenced by testability, but the main reason is I realized that external callers cannot directly use NetUtils.getCanonicalUri(...) since FileSystem#getDefaultPort() is a protected method. It seems natural to publicly expose getUri() and getCanonicalUri() , but if you disagree, I will try to change it.
          Hide
          Daryn Sharp added a comment -

          Reduced public visibility of FileSystem#getCanonicalUri().
          Shuffled the tests around.

          Show
          Daryn Sharp added a comment - Reduced public visibility of FileSystem#getCanonicalUri() . Shuffled the tests around.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12501154/HDFS-2450-4.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 9 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1474//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501154/HDFS-2450-4.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1474//console This message is automatically generated.
          Hide
          Daryn Sharp added a comment -

          Per suresh, renamed test resolver class, and upgraded FileSystem#getCanonicalUri() visibility to protected.

          Show
          Daryn Sharp added a comment - Per suresh, renamed test resolver class, and upgraded FileSystem#getCanonicalUri() visibility to protected.
          Hide
          Suresh Srinivas added a comment -

          +1 for the patch.

          Show
          Suresh Srinivas added a comment - +1 for the patch.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12501178/HDFS-2450-5.patch
          against trunk revision .

          +1 @author. The patch does not contain any @author tags.

          +1 tests included. The patch appears to include 9 new or modified tests.

          -1 patch. The patch command could not apply the patch.

          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1478//console

          This message is automatically generated.

          Show
          Hadoop QA added a comment - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12501178/HDFS-2450-5.patch against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/1478//console This message is automatically generated.
          Hide
          Matt Foley added a comment -

          Closed upon release of version 1.0.0.

          Show
          Matt Foley added a comment - Closed upon release of version 1.0.0.
          Hide
          Harsh J added a comment -

          Hey Daryn,

          I've not verified this by self but does trunk remain unaffected by this issue?

          Show
          Harsh J added a comment - Hey Daryn, I've not verified this by self but does trunk remain unaffected by this issue?
          Hide
          Daryn Sharp added a comment -

          I'll investigate.

          Show
          Daryn Sharp added a comment - I'll investigate.
          Hide
          Daryn Sharp added a comment -

          The actual code was brought into trunk quite a while back via porting of 205 dfs/hftp changes since there was a dependency. However, the slew of tests added in 205 were not carried over. I'll post a patch containing the tests.

          Show
          Daryn Sharp added a comment - The actual code was brought into trunk quite a while back via porting of 205 dfs/hftp changes since there was a dependency. However, the slew of tests added in 205 were not carried over. I'll post a patch containing the tests.
          Hide
          Harsh J added a comment -

          Thank you for taking a look Daryn

          Show
          Harsh J added a comment - Thank you for taking a look Daryn

            People

            • Assignee:
              Daryn Sharp
              Reporter:
              Rajit Saha
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development