Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-3359

DFSClient.close should close cached sockets

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.22.0, 2.0.0-alpha
    • Fix Version/s: 0.23.3, 2.0.2-alpha
    • Component/s: hdfs-client
    • Labels:
      None

      Description

      Some applications like the TT/JT (pre-2.0) and probably the RM/NM cycle through DistributedFileSystem objects reasonably frequently. So long as they call close() it isn't a big problem, except that currently DFSClient.close() doesn't explicitly close the SocketCache. So unless a full GC runs (causing the references to get finalized), many SocketCaches can get orphaned, each with many open sockets inside. We should fix the close() function to close all cached sockets.

      1. hdfs-3359-branch-0.23.txt
        2 kB
        Robert Joseph Evans
      2. hdfs-3359.txt
        3 kB
        Todd Lipcon
      3. hdfs-3359.txt
        3 kB
        Todd Lipcon

        Issue Links

          Activity

          Hide
          Tsz Wo Nicholas Sze added a comment -

          > Temp files are removed either by explicit close, or via an implicit close issued by the shutdown hooks. How can a long running client force the removal the temp files prior to exit?

          Sorry that I forgot to answer this question earlier. I think the deleteOnExit feature is for deleting files on exit, especially for unexpected exit, but not deleting the files "some time later". If a long running client wants to delete its temp files some time later, it probably should add the temp files to a list and then use the list to delete them later.

          Show
          Tsz Wo Nicholas Sze added a comment - > Temp files are removed either by explicit close, or via an implicit close issued by the shutdown hooks. How can a long running client force the removal the temp files prior to exit? Sorry that I forgot to answer this question earlier. I think the deleteOnExit feature is for deleting files on exit, especially for unexpected exit, but not deleting the files "some time later". If a long running client wants to delete its temp files some time later, it probably should add the temp files to a list and then use the list to delete them later.
          Hide
          Todd Lipcon added a comment -

          Can we continue the discussion on HDFS-3373?

          Show
          Todd Lipcon added a comment - Can we continue the discussion on HDFS-3373 ?
          Hide
          Kihwal Lee added a comment -

          If the client isn't explicitly closed, it appears the lease renewer holds a reference to it so the client will never be closed until exit.

          If there is nothing left to renew (i.e. all DFSOutputStreams are closed), the renewer thread will terminate after a delay. So, if user close all output streams, the renewer won't be the one holding the reference. DFSClient staying open likely means DistributedFileSystem isn't closed and has a reference to the client.

          Will this cause the client's leases to be renewed until exit? The renewer will shutdown if all clients are closed, but due to the aforementioned, this will never happen. Will this cause the process or a new thread to encounter lease problems when re-opening the file?

          The newer will shutdown if all DFSOutputStreams are closed, not necessarily DFSClients. Even if the renewer is active due to one forgotten stream, it won't affect others that are closed (NN has already removed the lease for those, so won't get renewed). So, the problem you mentioned will be confined to the files associated with the forgotten output streams.

          Show
          Kihwal Lee added a comment - If the client isn't explicitly closed, it appears the lease renewer holds a reference to it so the client will never be closed until exit. If there is nothing left to renew (i.e. all DFSOutputStreams are closed), the renewer thread will terminate after a delay. So, if user close all output streams, the renewer won't be the one holding the reference. DFSClient staying open likely means DistributedFileSystem isn't closed and has a reference to the client. Will this cause the client's leases to be renewed until exit? The renewer will shutdown if all clients are closed, but due to the aforementioned, this will never happen. Will this cause the process or a new thread to encounter lease problems when re-opening the file? The newer will shutdown if all DFSOutputStreams are closed, not necessarily DFSClients. Even if the renewer is active due to one forgotten stream, it won't affect others that are closed (NN has already removed the lease for those, so won't get renewed). So, the problem you mentioned will be confined to the files associated with the forgotten output streams.
          Hide
          Daryn Sharp added a comment -
          1. streams should be closed by users individually.

          Agreed, they should be, but accidents happen which results in leaks. Closing a FileSystem will force a hard close of all streams. How will FileContext provide the same functionality?

          1. client (DFSClient) is just a Java object.
          2. lease renewer is a global cache so that multiple being-written-files/DFSClients could share a single thread.

          If the client isn't explicitly closed, it appears the lease renewer holds a reference to it so the client will never be closed until exit. Will this cause the client's leases to be renewed until exit? The renewer will shutdown if all clients are closed, but due to the aforementioned, this will never happen. Will this cause the process or a new thread to encounter lease problems when re-opening the file?

          1. do you mean deleteOnExit by temp files? Anyway, deleteOnExit is handled by shutdown hooks.

          Temp files are removed either by explicit close, or via an implicit close issued by the shutdown hooks. How can a long running client force the removal the temp files prior to exit?

          Show
          Daryn Sharp added a comment - streams should be closed by users individually. Agreed, they should be, but accidents happen which results in leaks. Closing a FileSystem will force a hard close of all streams. How will FileContext provide the same functionality? client (DFSClient) is just a Java object. lease renewer is a global cache so that multiple being-written-files/DFSClients could share a single thread. If the client isn't explicitly closed, it appears the lease renewer holds a reference to it so the client will never be closed until exit. Will this cause the client's leases to be renewed until exit? The renewer will shutdown if all clients are closed, but due to the aforementioned, this will never happen. Will this cause the process or a new thread to encounter lease problems when re-opening the file? do you mean deleteOnExit by temp files? Anyway, deleteOnExit is handled by shutdown hooks. Temp files are removed either by explicit close, or via an implicit close issued by the shutdown hooks. How can a long running client force the removal the temp files prior to exit?
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-0.23-Build #248 (See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/248/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1334049)

          Result = SUCCESS
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1334049
          Files :

          • /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-0.23-Build #248 (See https://builds.apache.org/job/Hadoop-Hdfs-0.23-Build/248/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1334049) Result = SUCCESS todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1334049 Files : /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/branches/branch-0.23/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Tsz Wo Nicholas Sze added a comment -

          > client (DFSClient) is just a Java object.

          Let me clarify this:

          • The rpc proxy in DFSClient has its connection cache and the connections will timeout.
          • The newly added socket cache, which needs to be fixed, is not considered here.

          @Todd, thanks for filing HDFS-3373.

          Show
          Tsz Wo Nicholas Sze added a comment - > client (DFSClient) is just a Java object. Let me clarify this: The rpc proxy in DFSClient has its connection cache and the connections will timeout. The newly added socket cache, which needs to be fixed, is not considered here. @Todd, thanks for filing HDFS-3373 .
          Hide
          Todd Lipcon added a comment -

          BTW, I filed HDFS-3373

          Show
          Todd Lipcon added a comment - BTW, I filed HDFS-3373
          Hide
          Tsz Wo Nicholas Sze added a comment -

          Hi Daryn,

          • streams should be closed by users individually.
          • client (DFSClient) is just a Java object.
          • lease renewer is a global cache so that multiple being-written-files/DFSClients could share a single thread.
          • do you mean deleteOnExit by temp files? Anyway, deleteOnExit is handled by shutdown hooks.

          So close is not needed.

          Show
          Tsz Wo Nicholas Sze added a comment - Hi Daryn, streams should be closed by users individually. client (DFSClient) is just a Java object. lease renewer is a global cache so that multiple being-written-files/DFSClients could share a single thread. do you mean deleteOnExit by temp files? Anyway, deleteOnExit is handled by shutdown hooks. So close is not needed.
          Hide
          Daryn Sharp added a comment -

          There is no close() in FileContext. Users are not supposed to close FileContext.

          Out of curiosity, why is that? Let's say I have a long running process. If I can't do the following, how can I ensure the streams, clients, leases, and temp files are cleaned up before exit?

          FileContext fc = FileContext.getFileContext(path);
          try {
            ... do some stuff that might go boom! ...
          } finally {
            fc.close();
          }
          
          Show
          Daryn Sharp added a comment - There is no close() in FileContext. Users are not supposed to close FileContext. Out of curiosity, why is that? Let's say I have a long running process. If I can't do the following, how can I ensure the streams, clients, leases, and temp files are cleaned up before exit? FileContext fc = FileContext.getFileContext(path); try { ... do some stuff that might go boom! ... } finally { fc.close(); }
          Hide
          Tsz Wo Nicholas Sze added a comment -

          Sure, let file a new JIRA.

          Show
          Tsz Wo Nicholas Sze added a comment - Sure, let file a new JIRA.
          Hide
          Tsz Wo Nicholas Sze added a comment -

          There is no close() in FileContext. Users are not supposed to close FileContext.

          Show
          Tsz Wo Nicholas Sze added a comment - There is no close() in FileContext. Users are not supposed to close FileContext.
          Hide
          Todd Lipcon added a comment -

          hm, that's an interesting point about FileContext. Why doesn't FileContext have a close() call in its API?

          The difficulty with making the cache global is that the cached sockets may have some implicit state associated – eg the SocketFactory that was used to construct them. This state may differ between different DFSClients in the same JVM.

          Can we open a new JIRA to deal with this case, since it seems any fix would be much more complicated?

          Show
          Todd Lipcon added a comment - hm, that's an interesting point about FileContext. Why doesn't FileContext have a close() call in its API? The difficulty with making the cache global is that the cached sockets may have some implicit state associated – eg the SocketFactory that was used to construct them. This state may differ between different DFSClients in the same JVM. Can we open a new JIRA to deal with this case, since it seems any fix would be much more complicated?
          Hide
          Tsz Wo Nicholas Sze added a comment -

          Hi Todd, FileContext won't call DFSClient.close(). So the socket cache won't be cleaned up in FileContext. I think we should either

          • change it from per DFSClient to per DFSInputStream; or
          • change it to a global static cache (like what we did for LeaseRenewer.)

          Thought?

          Show
          Tsz Wo Nicholas Sze added a comment - Hi Todd, FileContext won't call DFSClient.close(). So the socket cache won't be cleaned up in FileContext. I think we should either change it from per DFSClient to per DFSInputStream; or change it to a global static cache (like what we did for LeaseRenewer.) Thought?
          Hide
          Robert Joseph Evans added a comment -

          Thanks Todd

          Show
          Robert Joseph Evans added a comment - Thanks Todd
          Hide
          Todd Lipcon added a comment -

          Committed to branch-0.23 as well.

          Show
          Todd Lipcon added a comment - Committed to branch-0.23 as well.
          Hide
          Todd Lipcon added a comment -

          +1, will commit momentarily. Thanks Bobby.

          Show
          Todd Lipcon added a comment - +1, will commit momentarily. Thanks Bobby.
          Hide
          Kihwal Lee added a comment -

          +1 (non-binding) Looks good to me.

          Show
          Kihwal Lee added a comment - +1 (non-binding) Looks good to me.
          Hide
          Robert Joseph Evans added a comment -

          I really would like to see this fix go into 0.23 as well. The patch did not apply cleanly so I have created my own. If someone could please review and commit this to 0.23 I really would appreciate it.

          Show
          Robert Joseph Evans added a comment - I really would like to see this fix go into 0.23 as well. The patch did not apply cleanly so I have created my own. If someone could please review and commit this to 0.23 I really would appreciate it.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk #1069 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1069/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624)

          Result = SUCCESS
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk #1069 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1069/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624) Result = SUCCESS todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk #1034 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1034/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624)

          Result = FAILURE
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk #1034 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk/1034/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624) Result = FAILURE todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Mapreduce-trunk-Commit #2200 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2200/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624)

          Result = ABORTED
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Mapreduce-trunk-Commit #2200 (See https://builds.apache.org/job/Hadoop-Mapreduce-trunk-Commit/2200/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624) Result = ABORTED todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Todd Lipcon added a comment -

          Committed this to 2.0 and trunk.

          Release managers for 0.23.x and 0.22.x may want to backport this as well.

          Show
          Todd Lipcon added a comment - Committed this to 2.0 and trunk. Release managers for 0.23.x and 0.22.x may want to backport this as well.
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Common-trunk-Commit #2182 (See https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2182/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624)

          Result = SUCCESS
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Common-trunk-Commit #2182 (See https://builds.apache.org/job/Hadoop-Common-trunk-Commit/2182/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624) Result = SUCCESS todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk-Commit #2256 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2256/)
          HDFS-3359. DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624)

          Result = SUCCESS
          todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624
          Files :

          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java
          • /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #2256 (See https://builds.apache.org/job/Hadoop-Hdfs-trunk-Commit/2256/ ) HDFS-3359 . DFSClient.close should close cached sockets. Contributed by Todd Lipcon. (Revision 1333624) Result = SUCCESS todd : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1333624 Files : /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/CHANGES.txt /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/DFSClient.java /hadoop/common/trunk/hadoop-hdfs-project/hadoop-hdfs/src/test/java/org/apache/hadoop/hdfs/TestDistributedFileSystem.java
          Hide
          Eli Collins added a comment -

          +1 change looks great, test doesn't cover the abort case but that's OK. Nice catch!

          Agree the test failure is unrelated, I've seen this timeout before, filed HDFS-3364.

          Show
          Eli Collins added a comment - +1 change looks great, test doesn't cover the abort case but that's OK. Nice catch! Agree the test failure is unrelated, I've seen this timeout before, filed HDFS-3364 .
          Hide
          Todd Lipcon added a comment -

          Test failure seems unrelated - I ran it locally and it passed.

          Show
          Todd Lipcon added a comment - Test failure seems unrelated - I ran it locally and it passed.
          Hide
          Hadoop QA added a comment -

          -1 overall. Here are the results of testing the latest attachment
          http://issues.apache.org/jira/secure/attachment/12525483/hdfs-3359.txt
          against trunk revision .

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

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

          -1 javadoc. The javadoc tool appears to have generated 2 warning messages.

          +1 javac. The applied patch does not increase the total number of javac compiler warnings.

          +1 eclipse:eclipse. The patch built with eclipse:eclipse.

          -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings.

          +1 release audit. The applied patch does not increase the total number of release audit warnings.

          -1 core tests. The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs:

          org.apache.hadoop.hdfs.TestFileAppend4

          +1 contrib tests. The patch passed contrib unit tests.

          Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//testReport/
          Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//artifact/trunk/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html
          Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//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/12525483/hdfs-3359.txt against trunk revision . +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 new or modified test files. -1 javadoc. The javadoc tool appears to have generated 2 warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 eclipse:eclipse. The patch built with eclipse:eclipse. -1 findbugs. The patch appears to introduce 1 new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed these unit tests in hadoop-hdfs-project/hadoop-hdfs: org.apache.hadoop.hdfs.TestFileAppend4 +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//artifact/trunk/trunk/patchprocess/newPatchFindbugsWarningshadoop-hdfs.html Console output: https://builds.apache.org/job/PreCommit-HDFS-Build/2367//console This message is automatically generated.
          Hide
          Daryn Sharp added a comment -

          +1 Nice catch.

          Show
          Daryn Sharp added a comment - +1 Nice catch.
          Hide
          Todd Lipcon added a comment -

          Oops, accidentally posted partial patch. Take 2 uploading right one.

          Show
          Todd Lipcon added a comment - Oops, accidentally posted partial patch. Take 2 uploading right one.

            People

            • Assignee:
              Todd Lipcon
              Reporter:
              Todd Lipcon
            • Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development