JDBC connection to SQL Server hanging because of JDK 1.6.0_29

Lately I’ve been having an issue with one of my Sakai instances connecting to MS SQL Server[1]. The strange thing was that the exact same code and connection details were working on our test and prod boxes, just not on mine. The only difference was the operating system (RHEL for the other boxes, OS X for me).

I spent a lot of time troubleshooting with our DBA, setting up tracing etc. He could see some activity when the connection was requested, but nothing past that. On my side it was:

DEBUG au.edu.anu.services.dao.impl.TimetableDaoImpl - getLessons(ANCH1013_S1,2011)
DEBUG org.springframework.jdbc.core.JdbcTemplate - Executing SQL query [exec spcXtableClass_timetable_webservice 2011, 'ANCH1013_S1']
DEBUG org.springframework.jdbc.datasource.DataSourceUtils - Fetching JDBC Connection from DataSource

But then it would hang, forever. Even shutting down Tomcat wouldn’t stop that thread, it needed to be forcibly killed.

I finally found this article on stack overflow.com which exactly described my issue.

As it turns out this was caused by an issue introduced with the Java 1.6.0_29 update issued with the latest OS X Java update, as described in this bug report. The SQL server connection uses encryption and something was changed in this area by the Java update. This was manifested via the SQL Server JDBC connection and some more info is in this bug report. This has been fixed in 1.6.0_30 but isn’t in any Apple package.

One solution proposed was upgrading to Java 7, but I wasn’t prepared to do that since there isn’t an official package yet and I don’t want to bust my primary work machine. But another solution mentioned replacing the jsse.jar from an older install which reverts the regression. One of my colleagues hadn’t upgraded yet (was still on 1.6.0_22), so I grabbed his jsse.jar and overwrote my own.

Problem solved.

/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Classes/jsse.jar

Now if only Apple would release Java packages a bit quicker…


[1] In case you were wondering, no, we don’t run the entire Sakai stack with SQL Server, just some applications within it – we have an instance separate from our main collaboration and research environment that we use for admin applications and web services.