JDK-6771432 : createSocket() - smpatch fails using 1.6.0_10 because of "Unconnected sockets not implemented"
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.2_19,6u10,6u12
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux_redhat_6.2,solaris,solaris_10,windows_2000 linux_redhat_6.2,solaris,solaris_10,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2008-11-14
  • Updated: 2011-12-17
  • Resolved: 2009-02-09
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.
Other Other Other JDK 6 JDK 7 Other
1.4.2_26-rev,OpenJDK6Fixed 1.4.2_27Fixed 5.0u25Fixed 6u12-rev b05Fixed 7Fixed OpenJDK6Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
smpatch checks /usr/jdk for the latest java installation.

When 1.6.0_10 is installed in /usr/jdk , smpatch fails with an error "Unconnected sockets not implemented".

I did some searching and found:
http://www.nabble.com/CXF-and-Java-6-Update-10-td19463818.html

Which is talking about another program that also gets this error when 1.6.0_10 is used. They say:
"I was able to reproduce this.  Fortunately, it's an easy fix (3 lines added to
our SSLSocketFactoryWrapper class).

Basically, older JDK's called the "createSocket" methods that take parameters
and create connected sockets.  The newer JDK seems to call the createSocket()
method (no params) and then connects it later.   However, we were not
forwarding that call into the wrapped socketfactory.   Once I add that, our
https tests pass.

I'm going to run the full test suite and if OK, I'll get it committed and
merged down through so the next releases should be fine. "
-----

... For smpatch, it works fine with java 1.5.0_16, and works with 1.6.0_07
It fails as soon as 1.6.0_10 is installed.

I suspect it's related to the above change to the JVM.

This would mean that older programs that ran fine on 1.6.0_07 and 1.5 may not work on 1.6.0_10 and above - it makes certain programs like smpatch no longer compatible... 

It seems some software out there is dealing with this by changing their source code, but they shouldn't have to if this is indeed a bug in 1.6.0_10.

reference to the smpatch code regarding creating of sockets:

http://opengrok.sfbay/source/xref/SWPatchTools-br_100/src/bundled/app/ppro/sw/classes/com/sun/patchpro/util/CustomSSLSocketFactory.java
http://opengrok.sfbay/source/xref/SWPatchTools-br_100/src/bundled/app/ppro/sw/classes/com/sun/patchpro/security/SSLTunnelSocketFactory.java

From a cursory look, these exist primarily to allow for custom timeouts on the connections we make with them.

What I don't see is any no argument createSocket() constructors in these classes. 
Matthew:  If the no-arg createSocket() is what is being called then wouldn't the superclass implementation in java.net.ssl.SSLSocketFactory be used? Are you suggesting that we override the no argument implementation of SSLSocketFactory in our SocketFactory classes?

Or is it that we should be changing the sequencing somehow in the usage of the the Socket (I assume we need to keep the sequence open a connection and then set the socket factory?)

I'd like to be clear that since the same code is used by clients with earlier JVMs as well as new ones, any solution we put in place needs to work simultaneously on older (Java 5) and new JVMs.

For reference the most obvious clients of these Socket Factories:
http://opengrok.sfbay/source/xref/SWPatchTools-br_100/src/bundled/app/ppro/sw/classes/com/sun/patchpro/util/Downloader.java
http://opengrok.sfbay/source/xref/SWPatchTools-br_100/src/bundled/app/ppro/sw/classes/com/sun/patchpro/server/ServerPatchServiceProvider.java
http://opengrok.sfbay/source/xref/SWPatchTools-br_100/src/bundled/app/ppro/sw/classes/com/sun/patchpro/server/UnifiedServerPatchServiceProvider.java

Comments
WORK AROUND For anyone who is suffering this problem using smpatch or updatemanager we have a workaround; edit the following lines: /usr/sbin/pprosvc:JAVACMD="/usr/jdk/latest/bin/java -version:1.5+" /usr/bin/updatemanager:JAVA_EXEC="/usr/jdk/latest/bin/java -version:1.5+" And change them to: /usr/sbin/pprosvc:JAVACMD="/usr/jdk/latest/bin/java -version:1.5*" /usr/bin/updatemanager:JAVA_EXEC="/usr/jdk/latest/bin/java -version:1.5*"
04-02-2009

EVALUATION To maintain backward compatibility we plan to fix this bug by failing back to the old way of creating sockets if the supplied factory does not override the default no args createSocket.
07-01-2009

WORK AROUND The custom SocketFactory should override the no-args createSocket() method. *** (#1 of 1): [ UNSAVED ] ###@###.###
17-11-2008

EVALUATION This is as a reault of the changes for CR 6614957.
17-11-2008