This content has been marked as final. Show 30 replies
From my point of view the following options exist.
1. Verify that the different drivers fail with a direct connection. I would do this myself. Use the simplest connection string possible.
2. I would also try a completely different database as well such as Oracle. I would also try Derby.
If both fail then it might be easier to convince customers that the version is broken.
Presumably the version is broken in some way. Given that it is then the following options exist
1. Do not support that version for the app. To be safe code something that will refuse to start the app if that version is in use.
2. If you must support it then options are
A. Get a real service contract with Oracle. Get them to produce a solution
B. Per previous replies source code probably isn't available but decompiling might be possible if the problem area can be localized. Create a bootclass overlay that fixes it. Whether you can deliver this requires a lawyer.
C. Use an IP sniffer to determine how the IP traffic is different. That might help with b. Since jTDS code is available it might be possible to code a solution from that.
D. Provide a proxy solution. Wrap a previous VM, put the real connection there, provide a socket API that does JDBC. Then the new JDK app manages it via that. Obviously a rather hokey solution but one that is conceptually easier than B/C and guaranteed to work. It might cost less than A and might produce a solution sooner as well.
Thanks for the information. I would like confirm that it worked for me.
I used jsse.jar from 1.6.0_27 in 1.6.0_29 and that solved the hanging problem with the SQL Server JDBC.
Furthermore, by reversing that action I was able to reproduce the issue at will.
I have not used SSL in my web applications. Can the jsse.jar fix the error?
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:
Either of these have to be set before the JSSE library is loaded.
If you cannot post the debug log in the forum, please attach it and send mail to firstname.lastname@example.org. Thanks in advance.
What does JSSE have to do with it? There are no JSSE classes anywhere in that stack trace.
we are hit by the same issue. When the fix will be released?
An early access (pre-release/non-production) version of 6u30 b12 was made available yesterday:
Looks like 1.6.0_30 was just released.
We just upgraded our Java to 1.6.0_30. A simple test program that opens a JDBC connection (using jTDS 1.2.2) to MS SQL Server 2008 R2 still fails with a "Connection reset" exception.
Using the -Djavax.net.debug=all flag, I can see that some data is initially being written to and read from the SQL Server; however, right after the server responds with "Changed database context to ...", etc., the client tries to write some commands (SELECT @@MAX_PRECISION, SET TRANSACTION ISOLATION LEVEL, etc.), and the server responds with:
main, handling exception: java.net.SocketException: Software caused connection abort: recv failedI saw that bug 7103725 is in "fix delivered" status, but this behavior still sounds like the same problem to me. I updated my SQL Server 2008 R2 to Service Pack 1 with no change; I did not apply any hot fixes beyond that because I did not see any mention of this issue in the knowledge base articles.
%% Invalidated: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
main, SEND TLSv1 ALERT: fatal, description = unexpected_message
If anyone has successfully connected to MS SQL Server R2 with JDBC using Java update 30, can you tell me what version of SQL Server you are using?
Also, if I can supply any more information please let me know.
Edited by: 905261 on Dec 30, 2011 2:24 PM
'Software caused connection abort' is not the same thing as 'connection reset'. The former is caused by your end in response to network errors; the tater is caused by the other end under a number of conditions. There is an MSDN article on the former.
Not sure I understand your response. When I run my test client I get a "connection reset" exception. When I run it with the javax.net.debug=all flag, the diganostic output reports a "recv failed" error; the server seems to have closed the connection at that point.
That is my point. There are two different failure modes here.
I apologize; I should have been clearer when I posted my original question. The article you mention (if I have the right one) simply says that there are all kinds of network errors that can cause a connection abort, which is true, but my problem seems to be specifically related to the subject of this thread.
With Java update 27 and earlier, I can connect to MS SQL Server 2008 R2 (SP1) using JDBC and SSL with absolutely no problems. With update 29 (and now 30), I cannot connect at all to the same exact server. It does not matter whether I try to connect across the network or on the local host where SQL Server resides. Whatever is ultimately causing the connection to be aborted, the one thing that triggers or prevents it is the Java version being used.
Removing the SSL parameter from the database URL makes the problem go away, of course. Also, connecting to MS SQL Server 2005 works perfectly with both update 30 and pre-29 (I used 21 to test).
Has anyone had any luck connecting to MS SQL Server 2008 R2 using Java update 30? It would be helpful to know whether bug 7103725 has truly been fixed, in which case I need to figure out what is wrong with my SQL Server.
The release notes say that Java release 1.6.0_30 contains a fix for bug 7103725.
However, the behavior when trying to connect to MS SQL Server 2008 R2 is identical to Java 1.6.0_29, when the bug was introduced: after some exchange between the client and the database server, the connection aborts with a "recv failed" error. To me it sounds like JSSE is still sending a packet that SQL Server is not expecting, which makes it close the connection.
Again, Java 220.127.116.11 and earlier work with no problems with exactly the same server and client.
So I am wondering whether the bug fix did not completely address the problem connecting to SQL Server 2008 introduced with Java 1.6.0_29.