Hi Griffin

I am able to reproduce your scenario where Synapse seems to stop responding, when a SSL handshake failure happens - and I am quite sure that its the same thing thats happening at your end too. If you run Synapse with -Djavax.net.debug=all this would be evident. Also if you are using the SVN trunk - get the latest code - I did a minute fix to the ClientHandler.java to print the stack trace that will help you debug the issue easily. Also check if you are getting the ClientHandler - I/O error: General SSLEngine problem in your logs?

[I/O reactor worker thread 1] DEBUG Axis2HttpRequest - get source channel of the pipe on which the outgoing response is written
....
I/O reactor worker thread 1, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I/O reactor worker thread 1, SEND TLSv1 ALERT:  fatal, description = certificate_unknown
I/O reactor worker thread 1, WRITE: TLSv1 Alert, length = 2
I/O reactor worker thread 1, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLHandshakeException: General SSLEngine problem
[I/O reactor worker thread 1] ERROR ClientHandler - I/O error : General SSLEngine problem
That seems like a good idea.  The interesting thing is that I didn't provide
addressing headers to begin with, they seem to have been added by Synapse.
  
Yes, this seems like a bug .. Could you please raise a JIRA for it, and we will fix it
Also with regard to this endpoint, is there a way to control the protocol
behaviours - i.e. disable Transfer-Encoding: chunked.
  
No, this is left to the transport implementation to decide, and as we do not read the complete message from the wire into memory before we parse it, we do not know the size of the message - hence most of the time the chunked encoding is used. Same applies during a write as its possible that we do not know the size when we start to write the message to the wire. But this should have *no* impact on your application as its purely a transport decision.
In my attempt to get the outbound HTTPS proxy to work, I've found that if I
use SOAP-UI and configure the key and truststores as I have them with the
Synapse/Axis2 httpniosslsender I am able to complete the request.  The
differences that I see in the debug streams are related to the HTTP header
and the user of the Transfer-Encoding - the NIOSSL sender uses
Transfer-Encoding: chunked and the Jakarta commons HTTP client used by
SOAP-UI uses Content-Length: xxx instead.
  
No I am positive that its not the chunked encoding, but the keystores.. I think its Synapse that doesn't trust your server. Could you tell me what your service host is? Is it Axis2/.net? and can does it use a self signed cert or CA cert? have you imported its cert or the CA cert into the trust store of Synapse?..

asankha



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to