JDK-7016003 : OpenDS fails to start up on Solaris starting JDK 7 b126
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2011-01-31
  • Updated: 2011-03-10
  • Resolved: 2011-03-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-7016078 - javax.net.ssl.SSLException: Received fatal alert: internal_error starting JDK 7 b126
Relates :  
JDK-6996367 - improve HandshakeHash
Relates :  
JDK-6996365 - Evaluate the priorities of cipher suites
Description
OpenDS fails to start up starting with JDK 7 b126 (also with b127, works fine with JDK 7 b125). There are exception during setup phase:

Jan 31, 2011 4:35:57 AM org.opends.quicksetup.util.ServerController startServer
WARNING: Could not connect to server: javax.naming.CommunicationException: Connection timed out [Root exception is java.net.ConnectException: Connection timed out]
javax.naming.CommunicationException: Connection timed out [Root exception is java.net.ConnectException: Connection timed out]
        at org.opends.admin.ads.util.ConnectionUtils.getInitialLdapContext(ConnectionUtils.java:713)
        at org.opends.admin.ads.util.ConnectionUtils.createLdapsContext(ConnectionUtils.java:233)
        at org.opends.quicksetup.util.Utils.createLdapsContext(Utils.java:1084)
        at org.opends.quicksetup.util.ServerController.startServer(ServerController.java:512)
        at org.opends.quicksetup.util.ServerController.startServer(ServerController.java:317)
        at org.opends.quicksetup.installer.offline.OfflineInstaller.run(OfflineInstaller.java:146)
        at org.opends.server.tools.InstallDS.execute(InstallDS.java:572)
        at org.opends.server.tools.InstallDS.mainCLI(InstallDS.java:335)
        at org.opends.server.tools.InstallDS.mainCLI(InstallDS.java:279)
        at org.opends.quicksetup.installer.SetupLauncher.launch(SetupLauncher.java:138)
        at org.opends.quicksetup.installer.SetupLauncher.main(SetupLauncher.java:75)
Caused by: java.net.ConnectException: Connection timed out
        at org.opends.admin.ads.util.ConnectionUtils.getInitialLdapContext(ConnectionUtils.java:712)
        ... 10 more
Adding -Dcom.sun.net.ssl.enableECC=false makes OpenDS run with JDK 7 b126.
Comments
EVALUATION From the debug log, it seems that the underlying issue is the same as CR 7016078. Please waiting for the feedback from CR 7016078 before making furhter evaluation.
01-02-2011
EVALUATION Also, if you could describe the architecture of how OpenDS is put together, that will help. For example, is the machine where the hang occurs receiving requests from clients, and then sending those requests on to another server? Which connection(s) is(are) hanging, etc.
01-02-2011
EVALUATION Of the two suggested bug fixes that introduced this problem, it's more likely that it's something we did with making the ECC ciphersuites a higher priority. The changes in HandshakeHash are core to any TLS interop testing, so I'm not thinking the problem is here. ###@###.###, can you please do two things for us? Please rerun this test with the Security Property active: -Djavax.net.debug=all and then a second time with: -Djavax.net.debug=all -Dcom.sun.net.ssl.enableECC=false and attach the output. If possible, please include the absolute minimum number of connections to show the issue. Also, what is the peer you're connecting to, and how old is it? Has it been updated recently? It's possible that it can't parse the TLS ECC extensions. Thanks.
31-01-2011