Life was good when our clients and server were running java 1.5.X. Now after some of our clients have upgraded to 1.6.0_1, life isn't so good.
I am seeing seemingly random exceptions that appear to be generated down in the guts of the https api layer. I could use your help.
Please, I appreciate any advice.
Here is the setup:
1) Tomcat 5.5.15 with jdk 1.5.0_09
2) Tomcat setup for https and http but https forced. Not using APR...
3) Clients are running jre 1.6.0_01.
4) Clients login and run a fairly large applet.
5) At some random point during the communication (we are serializing plain old java objects) the following exception occurs and all communication with the server is foobar until the browser is restarted. (Refresh doesn't help).
6) the above problem happens quicker for some and not at all for others.
The problem:
The clients are randomly failing (at least it seems that way) with
javax.net.ssl.SSLException: java.lang.NullPointerException
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)
at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source)
at com.mycompany.hm.callq.client.common.HttpMessage.sendPostObject(HttpMessage.java:227)
at com.mycompany.hm.callq.client.common.CallQSerializeData.sendViaHttp(CallQSerializeData.java:132)
at com.mycompany.hm.callq.client.common.SessionMonitor.getSessionInterval(SessionMonitor.java:355)
at com.mycompany.hm.callq.client.common.SessionMonitor.startSessionMonitorTimers(SessionMonitor.java:78)
at com.mycompany.hm.callq.client.common.JDockingApplet.start(JDockingApplet.java:331)
at sun.applet.AppletPanel.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NullPointerException
at com.sun.deploy.security.X509ExtendedDeployTrustManager.isSupportedAlgorithm(Unknown Source)
at com.sun.deploy.security.X509ExtendedDeployTrustManager.checkServerTrusted(Unknown Source)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source)
at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source)
at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source)
... 13 more
Once this happens, the java cache (apparently) becomes corrupted and must be deleted before the applet can be used (until it randomly fails again). The java console shows unable to load a class that I know exists and is fine...
I'm really hoping someone has some ideas. I'm in the process of seeing if upgrading to 1.6.1 on the server fixes the problem but I've already found one condition that it fails (consistently).
I don't know where to go from here?
-Dennis