Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-2386

with security enabled fsck calls lead to handshake_failure and hftp fails throwing the same exception in the logs

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 0.20.205.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Issue Links

        Activity

        Arpit Gupta created issue -
        Hide
        Arpit Gupta added a comment -

        fsck command ran and the following stack trace was seen

        Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1774)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
        at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434)
        at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
        at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
        at org.apache.hadoop.hdfs.tools.DFSck$1.run(DFSck.java:141)
        at org.apache.hadoop.hdfs.tools.DFSck$1.run(DFSck.java:110)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.security.auth.Subject.doAs(Subject.java:396)
        at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059)
        at org.apache.hadoop.hdfs.tools.DFSck.run(DFSck.java:110)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65)
        at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79)
        at org.apache.hadoop.hdfs.tools.DFSck.main(DFSck.java:182)

        Show
        Arpit Gupta added a comment - fsck command ran and the following stack trace was seen Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:136) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1774) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:954) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149) at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:434) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234) at org.apache.hadoop.hdfs.tools.DFSck$1.run(DFSck.java:141) at org.apache.hadoop.hdfs.tools.DFSck$1.run(DFSck.java:110) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1059) at org.apache.hadoop.hdfs.tools.DFSck.run(DFSck.java:110) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:65) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:79) at org.apache.hadoop.hdfs.tools.DFSck.main(DFSck.java:182)
        Hide
        Arpit Gupta added a comment -

        from the namenode logs

        2011-09-29 16:03:55,496 WARN org.mortbay.log: EXCEPTION
        javax.net.ssl.SSLHandshakeException: Invalid padding
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1699)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:852)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:708)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
        Caused by: javax.crypto.BadPaddingException: Padding length invalid: 92
        at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:399)
        at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247)
        at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:840)

        Show
        Arpit Gupta added a comment - from the namenode logs 2011-09-29 16:03:55,496 WARN org.mortbay.log: EXCEPTION javax.net.ssl.SSLHandshakeException: Invalid padding at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1699) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:852) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149) at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:708) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: javax.crypto.BadPaddingException: Padding length invalid: 92 at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:399) at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247) at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:840)
        Arpit Gupta made changes -
        Field Original Value New Value
        Link This issue is duplicated by HDFS-2387 [ HDFS-2387 ]
        Arpit Gupta made changes -
        Summary fsck calls lead to handshake_failure fsck calls lead to handshake_failure and hftp fails throwing the same exception in the logs
        Hide
        Arpit Gupta added a comment -

        Run a dfs command with the path specified as hftp leads to the following issue

        bash-3.2$ /bin/hadoop --config HADOOP_CONF_DIR dfs -ls hftp://NN_HOST:50070/path
        11/09/29 16:07:23 INFO fs.FileSystem: Couldn't get a delegation token from https://NN_HOST:50470 using https.
        ls: Security enabled but user not authenticated by filter

        The namenode logs has the same exception as in the above comment.

        Show
        Arpit Gupta added a comment - Run a dfs command with the path specified as hftp leads to the following issue bash-3.2$ /bin/hadoop --config HADOOP_CONF_DIR dfs -ls hftp://NN_HOST:50070/path 11/09/29 16:07:23 INFO fs.FileSystem: Couldn't get a delegation token from https://NN_HOST:50470 using https. ls: Security enabled but user not authenticated by filter The namenode logs has the same exception as in the above comment.
        Hide
        Aaron T. Myers added a comment -

        Seems like fsck not working should be a blocker.

        Show
        Aaron T. Myers added a comment - Seems like fsck not working should be a blocker.
        Aaron T. Myers made changes -
        Priority Major [ 3 ] Blocker [ 1 ]
        Hide
        Owen O'Malley added a comment -

        Did you remember to set the property:

        <property>
        <name>dfs.https.enable</name>
        <value>true</value>
        </property>

        It needs to be set in the NameNode's config and not the DataNode's config.

        Show
        Owen O'Malley added a comment - Did you remember to set the property: <property> <name>dfs.https.enable</name> <value>true</value> </property> It needs to be set in the NameNode's config and not the DataNode's config.
        Hide
        Arpit Gupta added a comment -

        That property was not present in the namenode however even after adding the property and restarting the namenode same issue still exists.

        Show
        Arpit Gupta added a comment - That property was not present in the namenode however even after adding the property and restarting the namenode same issue still exists.
        Hide
        Jitendra Nath Pandey added a comment -

        I installed a 6 node cluster and it works for me. This seems to be something cluster/machine specific. I used java version jdk1.6.0_27.

        Show
        Jitendra Nath Pandey added a comment - I installed a 6 node cluster and it works for me. This seems to be something cluster/machine specific. I used java version jdk1.6.0_27.
        Hide
        Aaron T. Myers added a comment -

        Arpit and Jitendra: am I correct in assuming that both of you were testing this on clusters with security enabled? If so, what encryption types did you each use for you keytabs/principals?

        Show
        Aaron T. Myers added a comment - Arpit and Jitendra: am I correct in assuming that both of you were testing this on clusters with security enabled? If so, what encryption types did you each use for you keytabs/principals?
        Hide
        Owen O'Malley added a comment -

        Also make sure that your java home has the jce security stuff added to it.

        http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

        Show
        Owen O'Malley added a comment - Also make sure that your java home has the jce security stuff added to it. http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
        Hide
        Matt Foley added a comment -

        So far, on three clusters we've tried this on, it worked fine in two. Only our QA system test cluster experienced the difficulty. We are continuing to investigate, however, at this time we do not consider it a blocker because it is more likely due to a problem with the cluster setup than with the code.

        When we identify the issue we will share it here.

        Show
        Matt Foley added a comment - So far, on three clusters we've tried this on, it worked fine in two. Only our QA system test cluster experienced the difficulty. We are continuing to investigate, however, at this time we do not consider it a blocker because it is more likely due to a problem with the cluster setup than with the code. When we identify the issue we will share it here.
        Matt Foley made changes -
        Priority Blocker [ 1 ] Major [ 3 ]
        Hide
        Matt Foley added a comment -

        And of course if it does turn out to be due to a code problem, will re-raise the "blocker" severity.

        Show
        Matt Foley added a comment - And of course if it does turn out to be due to a code problem, will re-raise the "blocker" severity.
        Hide
        Aaron T. Myers added a comment -

        Matt: That seems reasonable. Thanks for the info.

        I also suspect that the description of this JIRA should be changed to "With security enabled, [rest of description]." Do you agree?

        Show
        Aaron T. Myers added a comment - Matt: That seems reasonable. Thanks for the info. I also suspect that the description of this JIRA should be changed to "With security enabled, [rest of description] ." Do you agree?
        Hide
        Arpit Gupta added a comment -

        Aaron you are correct, description updated.

        Show
        Arpit Gupta added a comment - Aaron you are correct, description updated.
        Arpit Gupta made changes -
        Summary fsck calls lead to handshake_failure and hftp fails throwing the same exception in the logs with security enabled fsck calls lead to handshake_failure and hftp fails throwing the same exception in the logs
        Hide
        Jitendra Nath Pandey added a comment -

        @Aaron
        From kerberos debug logs the encryption used between nodes in my cluster seems to be DES_CBC_CRC.

        Show
        Jitendra Nath Pandey added a comment - @Aaron From kerberos debug logs the encryption used between nodes in my cluster seems to be DES_CBC_CRC.
        Hide
        Allen Wittenauer added a comment -

        FWIW, we are actively hitting this issue with the secondary namenode and fsck with the 204. JDK 1.6.0_29, RHEL 6.1, MIT 1.8.x, AES-256, AES-128, and RC4 enc types are enabled. JCE is installed.

        We see on the NN side that we throw an invalid_padding error while the 2nd NN and fsck throw the handshake_failure message.

        At this point, I'm leaning towards ripping out the SSL code from the namenode and running at least that portion unsecured.

        Show
        Allen Wittenauer added a comment - FWIW, we are actively hitting this issue with the secondary namenode and fsck with the 204. JDK 1.6.0_29, RHEL 6.1, MIT 1.8.x, AES-256, AES-128, and RC4 enc types are enabled. JCE is installed. We see on the NN side that we throw an invalid_padding error while the 2nd NN and fsck throw the handshake_failure message. At this point, I'm leaning towards ripping out the SSL code from the namenode and running at least that portion unsecured.
        Hide
        Jitendra Nath Pandey added a comment -

        Can you try with DES_CBC_CRC? It is also available in Java 6 by default.

        Show
        Jitendra Nath Pandey added a comment - Can you try with DES_CBC_CRC? It is also available in Java 6 by default.
        Hide
        Jakob Homan added a comment -

        At this point, I'm leaning towards ripping out the SSL code from the namenode and running at least that portion unsecured.

        Now that we have a SPNEGO filter, we no longer need to use Kerberized SSL. It would be good to remove that entirely. It was added as a work-around to having no suitable SPNEGO solution and is rather unique to Hadoop (although apparently ActiveMQ took the code as well). This would save us from having to use the host principal (and instead use the more standard http principal) and simplify a lot of the config.

        Show
        Jakob Homan added a comment - At this point, I'm leaning towards ripping out the SSL code from the namenode and running at least that portion unsecured. Now that we have a SPNEGO filter, we no longer need to use Kerberized SSL. It would be good to remove that entirely. It was added as a work-around to having no suitable SPNEGO solution and is rather unique to Hadoop (although apparently ActiveMQ took the code as well). This would save us from having to use the host principal (and instead use the more standard http principal) and simplify a lot of the config.
        Hide
        Aaron T. Myers added a comment -

        +1 to Jakob's recommendation. In practice, I've found setting up a 2NN to successfully checkpoint to be the most annoying and difficult-to-debug part of configuring secure Hadoop.

        Show
        Aaron T. Myers added a comment - +1 to Jakob's recommendation. In practice, I've found setting up a 2NN to successfully checkpoint to be the most annoying and difficult-to-debug part of configuring secure Hadoop.
        Hide
        Allen Wittenauer added a comment -

        > Can you try with DES_CBC_CRC?

        No, because at that level you might as well send it across the wire unencrypted.

        Show
        Allen Wittenauer added a comment - > Can you try with DES_CBC_CRC? No, because at that level you might as well send it across the wire unencrypted.
        Hide
        Rajesh Balamohan added a comment -

        >>
        we are actively hitting this issue with the secondary namenode and fsck with the 204. JDK 1.6.0_29, RHEL 6.1, MIT 1.8.x, AES-256, AES-128, and RC4 enc types are enabled. JCE is installed.
        >>

        +1, We are facing this issue as well and get the following exception in NameNode.

        11/12/29 18:47:02 WARN mortbay.log: EXCEPTION
        javax.net.ssl.SSLHandshakeException: Invalid padding
        at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1699)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:852)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149)
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:708)
        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
        Caused by: javax.crypto.BadPaddingException: Padding length invalid: 238
        at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:399)
        at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247)
        at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153)
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:840)
        ... 5 more

        Pasting the javax.net.debug output from secondary namenode (if this would be of help)

        Enabled javax.net.debug=all in secondary namenode and got the following output

        Cipher Suite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA
        Compression Method: 0
        Extension renegotiation_info, renegotiated_connection: <empty>
        ***
        %% Created: [Session-1, TLS_KRB5_WITH_3DES_EDE_CBC_SHA]

          • TLS_KRB5_WITH_3DES_EDE_CBC_SHA
            • ServerHelloDone
            • ClientKeyExchange, Kerberos
              ...
              ...
              ..
            • Finished
              verify_data: { 190, 127, 20, 131, 10, 136, 84, 207, 172, 130, 31, 53 }

              ***
              main, WRITE: TLSv1 Handshake, length = 40
              main, READ: TLSv1 Alert, length = 2
              main, RECV TLSv1 ALERT: fatal, handshake_failure
              main, called closeSocket()
              main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
              11/12/29 18:47:02 ERROR namenode.SecondaryNameNode: checkpoint: Content-Length header is not provided by the namenode when trying to fetch https://NN:50475/getimage?getimage=1

        Show
        Rajesh Balamohan added a comment - >> we are actively hitting this issue with the secondary namenode and fsck with the 204. JDK 1.6.0_29, RHEL 6.1, MIT 1.8.x, AES-256, AES-128, and RC4 enc types are enabled. JCE is installed. >> +1, We are facing this issue as well and get the following exception in NameNode. 11/12/29 18:47:02 WARN mortbay.log: EXCEPTION javax.net.ssl.SSLHandshakeException: Invalid padding at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1699) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:852) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1149) at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:708) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: javax.crypto.BadPaddingException: Padding length invalid: 238 at com.sun.net.ssl.internal.ssl.CipherBox.removePadding(CipherBox.java:399) at com.sun.net.ssl.internal.ssl.CipherBox.decrypt(CipherBox.java:247) at com.sun.net.ssl.internal.ssl.InputRecord.decrypt(InputRecord.java:153) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:840) ... 5 more Pasting the javax.net.debug output from secondary namenode (if this would be of help) Enabled javax.net.debug=all in secondary namenode and got the following output Cipher Suite: TLS_KRB5_WITH_3DES_EDE_CBC_SHA Compression Method: 0 Extension renegotiation_info, renegotiated_connection: <empty> *** %% Created: [Session-1, TLS_KRB5_WITH_3DES_EDE_CBC_SHA] TLS_KRB5_WITH_3DES_EDE_CBC_SHA ServerHelloDone ClientKeyExchange, Kerberos ... ... .. Finished verify_data: { 190, 127, 20, 131, 10, 136, 84, 207, 172, 130, 31, 53 } *** main, WRITE: TLSv1 Handshake, length = 40 main, READ: TLSv1 Alert, length = 2 main, RECV TLSv1 ALERT: fatal, handshake_failure main, called closeSocket() main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure 11/12/29 18:47:02 ERROR namenode.SecondaryNameNode: checkpoint: Content-Length header is not provided by the namenode when trying to fetch https://NN:50475/getimage?getimage=1
        Hide
        Joey Echeverria added a comment -

        From testing I've been doing it looks like KSSL won't work without at least one of the DES encryption types enabled (e.g. DES_CBC_CRC). This looks like it's caused by a bug in the JDK. Basically, AES and RC4 don't pad unless they encrypt a message which is not a multiple of a block. However, the JDK is assuming that the PreMasterSecret will be padded and assumes that the last byte in the decrypted secret is the length of the padding. When using AES or RC4, this ends up being a random byte and usually will cause the JDK to end up with an invalid PreMasterSecret. In defense of this, the JDK generates a random secret that then caused the handshake to fail later on. I need to do some more testing with another version of Kerberos, but I plan on filing a JDK bug.

        Show
        Joey Echeverria added a comment - From testing I've been doing it looks like KSSL won't work without at least one of the DES encryption types enabled (e.g. DES_CBC_CRC). This looks like it's caused by a bug in the JDK. Basically, AES and RC4 don't pad unless they encrypt a message which is not a multiple of a block. However, the JDK is assuming that the PreMasterSecret will be padded and assumes that the last byte in the decrypted secret is the length of the padding. When using AES or RC4, this ends up being a random byte and usually will cause the JDK to end up with an invalid PreMasterSecret. In defense of this, the JDK generates a random secret that then caused the handshake to fail later on. I need to do some more testing with another version of Kerberos, but I plan on filing a JDK bug.
        Allen Wittenauer made changes -
        Link This issue is related to HDFS-2617 [ HDFS-2617 ]
        Hide
        Allen Wittenauer added a comment -

        We're been running with HDFS-2617 in place of the KSSL support for the past few months rather than deal with these issues.

        Show
        Allen Wittenauer added a comment - We're been running with HDFS-2617 in place of the KSSL support for the past few months rather than deal with these issues.
        Hide
        Joey Echeverria added a comment -

        HDFS-2617 is definitely the right solution for Hadoop. I still plan on filing the JDK bug to make the world a little less broken.

        Show
        Joey Echeverria added a comment - HDFS-2617 is definitely the right solution for Hadoop. I still plan on filing the JDK bug to make the world a little less broken.
        Hide
        Joey Echeverria added a comment -

        Looks like this was already filed and is fixed in JDK 7:

        http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6946669

        I recommend closing this ticket as either "Won't Fix" or "Duplicate" since this issue will be fixed in HDFS-2617 and I doubt there's anything we can do to make this work on JDK 6.

        Show
        Joey Echeverria added a comment - Looks like this was already filed and is fixed in JDK 7: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6946669 I recommend closing this ticket as either "Won't Fix" or "Duplicate" since this issue will be fixed in HDFS-2617 and I doubt there's anything we can do to make this work on JDK 6.
        Hide
        Owen O'Malley added a comment -

        Fixed via HDFS-2617.

        Show
        Owen O'Malley added a comment - Fixed via HDFS-2617 .
        Owen O'Malley made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Invalid [ 6 ]
        Suresh Srinivas made changes -
        Resolution Invalid [ 6 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Suresh Srinivas added a comment -

        Duplicate HDFS-2617 addresses this.

        Show
        Suresh Srinivas added a comment - Duplicate HDFS-2617 addresses this.
        Suresh Srinivas made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Duplicate [ 3 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        270d 8h 23m 1 Owen O'Malley 26/Jun/12 01:01
        Resolved Resolved Reopened Reopened
        176d 19h 56m 1 Suresh Srinivas 19/Dec/12 19:58
        Reopened Reopened Resolved Resolved
        16s 1 Suresh Srinivas 19/Dec/12 19:58

          People

          • Assignee:
            Unassigned
            Reporter:
            Arpit Gupta
          • Votes:
            0 Vote for this issue
            Watchers:
            14 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development