Java Axis2 클라이언트를 Websphere6/JRE1.5.x에서 Solaris의 Tomcat 7.0.42/JRE1.6.x로 마이그레이션하려고합니다. 이 과정에서 나는 클라이언트가 처음으로 https를 통해 웹 서비스와 통신 할 수 있지만 ssl 오류로 인해 두 번째 시도에서 실패 할 수있는 문제를 발견했습니다. 실패한 시도의 로그에서 추출Axis2 클라이언트가 Tomcat 7.0.42에서 두 번째 https 호출을 시작할 수 없습니다.
는보여 주었다 -
%% 클라이언트가 캐시 [세션 1, SSL_RSA_WITH_RC4_128_MD5] 포트에서 [세션 1, SSL_RSA_WITH_RC4_128_MD5]을 다시 시작하십시오 %%
34,092
* *의 ClientHello, TLSv1의
...
스레드 606 WRITE : 핸드 TLSv1의 길이 = 179
스레드 606 읽어 TLSv1의 경고> 길이 = 2
012,351 javax.net.ssl의 : - : 6,스레드 (606), RECV TLSv1의 ALERT에 의해를 일으켰
unexpected_message 치명적인, 실제 예외 (나는 그것이 더 열려있는 소켓에 기인 의심)이었다. SSLException가이 치명적인 경고를받은 : unexpected_message을 com.sun.net.ssl.internal.ssl.Alerts.getSSLException (알 수없는 소스)
에서 com.sun.net.ssl.internal.ssl.Alerts.getSSLException에서 (알 수없는 Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert (알 수없는 소스) 0 이 com.sun에서 com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake에서 com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord (알 소스) (알 소스)에 123, .net.ssl.internal.ssl.SSLSocketImpl.writeRecord (알 수없는 소스) com.sun.net.ssl.internal.ssl.AppOutputStream.write (알 수없는 소스) at java.io.BufferedOutputStream.flushBuffer (알 수없는 소스) 에서 org.apache.commons.httpclient.WireLogOutputStream.write (WireLogOutputStream.java:86) 에서 java.io.FilterOutputStream.write (알 소스)에 java.io.BufferedOutputStream.write (알 소스)의 조직도 .apache.axis2.tra
인가 - nsport.http.AxisRequestEntity.writeRequest (AxisRequestEntity.java:89) WebSphere 환경에 로그이 비교
, 나는 따라서 차이와 내 몇 가지 질문을 발견했다 다른 서버를 호출하는 Axis2 클라이언트의 동작에 영향을 미칠 Tomcat의 SSL 구성은 무엇입니까? 아니면 OS 레벨에서 내 문제가 더 많습니까?
이전 환경에서 두 개 이상의 SSL 세션이 캐시 된 것을 확인했습니다. 한 세션에서 이력서가 실패했을 때, 다른 세션을 사용하여 간단히 시도하고 통화를 계속했습니다. 그러나 새 서버에서는 한 세션 만 생성되고 캐시 된 것으로 나타났습니다. 다시 시작할 때 다른 포트에서 동일한 세션을 계속 재개하려고했지만 계속 실패했습니다. 유일한 세션 이었기 때문에 다른 세션을 시도하거나 새로운 세션을 만들 수없는 경우 내 질문은 왜 단 하나의 세션이 만들어지고 하나 이상의 세션의 캐싱을 활성화하는 구성 문제입니까?
어떤 도움이나 조언을 부탁드립니다.