Some clarifications below.
Jesus M. Salvo Jr. wrote:
What I am seeing with ethereal is that, after 30 seconds of no activity ( no TCP ACKs whatever on the socket ), the web server sends a a TLS alert.
So what actually happens is this:
1) Send one HTTP POST to a URL, which works and I get the response.
2) Sleep for 40 seconds ( which is greater than the SO_TIMEOUT of 30 seconds )
3) Web server sends a TLS alert after 30 seconds of inactivity. Web server sends a TCP FIN, Java sends a TCP ACK _only_ .
At this point, local socket is in CLOSE_WAIT state.
4) Wake up from sleep at the 40 second mark, send another HTTP POST to the same URL.
5) Receive a TLS alert instead of a HTTP response. The TLS alert according to JSSE's debug mode is:
main, RECV TLSv1 ALERT: warning, close_notify
main, called closeInternal(false)
main, SEND TLSv1 ALERT: warning, description = close_notify
Item (5) is actually not the webserver sending a TLS alert, but JSSE sending the TLS alert
6) HttpClient throws an HttpRecoverableException, shown below:
org.apache.commons.httpclient.HttpRecoverableException: org.apache.commons.httpclient.HttpRecoverableException: Error in parsing the status line from the response: unable to find line starting with "HTTP"
Question is, was I correct in initially assuming that MultiThreadedHttpConnectionManager should have "handled" this case ? e.g... .detected that the exception, and retried the HTTP POST by creating a new HTTPS socket ?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
