Axis2客户端无法在Tomcat 7.0.42上发起第二个https调用

Question

I am trying to migrate an Java Axis2 client from Websphere6/JRE1.5.x to Tomcat 7.0.42/JRE1.6.x on Solaris. In the process, I have come across a issue where the client can communicate with a webservice through https the first time, but would fail from the second attempt onwards due to ssl errors.

Extracted from the log of the failed attempts showed -

%% Client cached [Session-1, SSL_RSA_WITH_RC4_128_MD5]
%% Try resuming [Session-1, SSL_RSA_WITH_RC4_128_MD5] from port 34092
* * ClientHello, TLSv1
...
Thread-606, WRITE: TLSv1 Handshake, length = 179
Thread-606, READ: TLSv1 Alert, > length = 2
Thread-606, RECV TLSv1 ALERT: fatal, unexpected_message

and the actual exception was (I suspect it was due to no open socket)-

Caused by: javax.net.ssl.SSLException: Received fatal alert: unexpected_message at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.write(Unknown Source) at java.io.FilterOutputStream.write(Unknown Source) at org.apache.commons.httpclient.WireLogOutputStream.write(WireLogOutputStream.java:86) at org.apache.axis2.transport.http.AxisRequestEntity.writeRequest(AxisRequestEntity.java:89)

Comparing this to the logs on the Websphere environment, I have found a couple of differences and hence my questions -

1. Is SSL configuration on the Tomcat going to affect the behaviour of a Axis2 client calling a different server? Or is my issue more at the OS level?

2. on the old environment, I have noticed more than one ssl sessions were cached. When resume failed on one session, it simply tried using a different session and continued with the call. On the new server, however, I have ever only seen one session created and was cached. When resuming, it kept trying to resume the same sessionn a different port but kept failing. As it was the only session, if couldn't try a different session nor creating a new session. My question is why is there only one session created and is it a configuration issue to enable caching of more than one sessions?

Any help/pointers are greatly appreciated.

Answer 1

Finally tracked down the fault. Thought I would share it here for anyone that may come across a similar issue. As it turned out, it has to do with the Security Provider on the JRE itself. Here is a link on how to configure it -
http://pic.dhe.ibm.com/infocenter/ssp/v3r4/index.jsp?topic=%2Fcom.ibm.help.sspreleasenotes.doc%2FSSP_RN_RemovePKCS11SecurityProvider.html

It seemed the default security provider on Solaris was causing the weird behaviour I saw. Following the instruction in the link, and by using the Java default provider, resolved the ssl problem I saw.