JDK-7105007 : Microsoft & jTDS JDBC driver broken after update to 1.6.0_29
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 6u26,6u29
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    solaris_8,windows_xp,windows_2008,windows_7 solaris_8,windows_xp,windows_2008,windows_7
  • CPU: x86
  • Submitted: 2011-10-26
  • Updated: 2012-03-20
  • Resolved: 2011-11-16
Related Reports
Duplicate :  
JDK-7103886 - 6.0 u27 upgraded to u29: JDBC for SQLServer hangs on connect
Duplicate :  
JDK-7103725 - REGRESSION - 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA
Duplicate :  
JDK-7106332 - MSSQL JDBC Driver (Type4) deadlock while establishing connection
Description
FULL PRODUCT VERSION :
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
Microsoft JDBC Driver 2.0 / 3.0 / 4.0 CTP 3
SQL Server 2008R2

A DESCRIPTION OF THE PROBLEM :
Creating a JDBC connection through Microsoft JDBC Driver 2.0, 3.0, 4.0 CTP 3, or jTDS 1.2.5 driver to a Microsoft SQL server 2008R2 database using JDK 1.6.0_29 results in an indefinite wait for a connection. This worked fine on all previous versions from 1.6.0_27.

Interrupting the thread does not work, it has to be stopped.

REGRESSION.  Last worked in version 6u26

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run supported source with one of the mentioned Microsoft SQL Server drivers.
With version 1.6.0_29 this program will not terminate. With any other JVM version this will create a usable connection.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
  To see a line in console "Connected to database:"
ACTUAL -
None, program will not terminate, and needs to be stopped forcibly.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Stakctrace at the moment of thread stop:

    at java.net.SocketInputStream.socketRead0(Native Method) ~[na:1.6.0_29]
    at java.net.SocketInputStream.read(Unknown Source) ~[na:1.6.0_29]
    at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1647) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5026) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4978) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1441) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1446) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(SQLServerConnection.java:1907) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.access$000(SQLServerConnection.java:41) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection$LogonCommand.doExecute(SQLServerConnection.java:1893) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1045) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:817) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:700) ~[jdbc4-driver-3.0.jar:na]
    at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:842) ~[jdbc4-driver-3.0.jar:na]
    at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29]
    at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29]

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;

public class JdbcBug {

	public static void main(String[] args) throws SQLException {
		Properties connectionProps = new Properties();
		connectionProps.put("user", "my_username");
		connectionProps.put("password", "my_password");

		Connection conn = DriverManager.getConnection("jdbc:sqlserver://localhost:1433",
				connectionProps);
		System.out.println("Connected to database: " + conn);
	}
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Revert to Java 1.6.0_27 or earlier version, or upgrade to 1.7.0_01. Or switch Microsoft database server. SQL Server 2008 , 2005, 2000 all work.
From http://stackoverflow.com/questions/7841411/driver-getconnection-hangs-using-sqlserver-driver-and-java-1-6-0-29/

    * OS: Tested on both redhat 6.1 and Windows 2008
    * Driver: MS SQL Server JDBC Driver version 3.0.1301.101
    * Java Versions: 1.6.0_26 and 1.6.0_29

    Windows 7 x64, JDK 1.6.0_29, SQL Express 2008 R2 (10.50.1790), using 
    sqljdbc4.jar, and it hangs on getConnection.

    Reproduced with SQL server 2008R2. SQL 2005 & 2008 work normally

VERY IMPORTANT HERE:

    Works on 7.1, but not on 6u29.
Comments
EVALUATION Two customers obtained 6u30 b12, and report that this fix addresses the problem.
28-11-2011
EVALUATION An early access (pre-release/non-production) version of 6u30 b12 was made available yesterday: http://jdk6.java.net/download.html
19-11-2011
EVALUATION I believe that all outstanding issues are now understood. This is a duplicate of 7103725. We've been able to reproduce, and the fix for 7103725 resolves the hang. Much of the debug info we got was from JSSE, the JDBC driver, and network packets (Solaris "snoop"). As part of the prenegotiation sequence, the MS JDBC Driver (I will call Driver) and the MS SQL Server (Server) negotiate whether encryption is required for the communication. There are two cases here: 1) If encryption is not required, an initial login is done with TLS to send the initial request/authentication. Then the connection drops back down to unencrypted. 7103725 was sending an extra SSL packet, and the Server didn't know how to handle the data as the Server was expecting a plaintext packet, and was waiting for additional data. As mentioned, upgrading to 7u1 is a possible solution until the fix is made available for JDK 6/5/4. Please see 7103725 for possible release vehicles for those environments. 2) If encryption is required, there is a different problem that we feel will need to be addressed by Microsoft. We have notified Microsoft of this incompatibility, and will be working with them.
16-11-2011
EVALUATION I've created a 6u29+7103725 JSSE build, the location of which is in the comments. Please test this to see if this resolves the issue.
02-11-2011
EVALUATION From http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/97dce8fd-6487-4bca-80b0-492167db3e0d Apparently, this is related to SSL use and can be mitigated by replacing the jsse.jar in the jre/lib with that from an earlier version, for instance out of the 1.6.0_27 release. I've been confused by 1.6.0_29 working with MS JDBC and older SQL Server '05 setups which are not doing secure connections. All the newer servers (SQL Server '08 R2) fail as they require SSL and Java 1.6.0_29 does not work using jTDS or MS JDBC in this case. ...and... I can confirm that jTDS fails just as MS supplied JDBC drivers fail using JVM 1.6.0_29 but both drivers work just fine using 1.6.0_27.
02-11-2011
EVALUATION According to NielsK, Debi, and aandea on the stackoverflow forum, it works fine on 7.1, but *NOT* on 6u29. This may not be related to the JSSE CPU fixes after all. Am hoping to get feedback from support on two issues. It's possible that this is the same issue as CR 7103725. Wondering if a SSL-protected connection throws an exception, perhaps it falls over to an unencrypted connection, which is then hanging. The stacktrace provided doesn't mention SSL at all.
02-11-2011
EVALUATION I'm continuing to look at this various reports for this bug, but it could be related to one of two JSSE changes that went into 6u29. It would really help us to debug this from the JSSE side if you could please run the most minimal version of the connection with the JSSE debugging turned on. That is: % java -Djavax.net.debug=all YourClass or within the application java.lang.System.setProperty("javax.net.debug", "all"); Either of these have to be set before the JSSE library is loaded. The support organization has also been asked to engage customers about another question. Waiting to hear from them.
02-11-2011
EVALUATION This is not a jdbc-odbc-bridge or a JDBC issue. The stacktrace shows at java.net.SocketInputStream.socketRead0(Native Method) ~[na:1.6.0_29] at java.net.SocketInputStream.read(Unknown Source) ~[na:1.6.0_29] at com.microsoft.sqlserver.jdbc.TDSChannel.read(IOBuffer.java:1647) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(IOBuffer.java:3694) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:5026) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.TDSCommand.startResponse(IOBuffer.java:4978) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection$1ConnectionCommand.doExecute(SQLServerConnection.java:1441) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectionCommand(SQLServerConnection.java:1446) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.logon(SQLServerConnection.java:1907) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.access$000(SQLServerConnection.java:41) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection$LogonCommand.doExecute(SQLServerConnection.java:1893) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.TDSCommand.execute(IOBuffer.java:4575) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(SQLServerConnection.java:1400) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.connectHelper(SQLServerConnection.java:1045) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.login(SQLServerConnection.java:817) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerConnection.connect(SQLServerConnection.java:700) ~[jdbc4-driver-3.0.jar:na] at com.microsoft.sqlserver.jdbc.SQLServerDriver.connect(SQLServerDriver.java:842) ~[jdbc4-driver-3.0.jar:na] at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29] at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29] This appears to be due to a change in SocketInputStream or related area in u29. This is being called from the JDBC driver implementation, which makes s ense. Please assign to the appropriate team and I am happy to provide input if needed.
01-11-2011