Persistent HTTPS connections

["Jesus M. Salvo Jr." <je...@migasia.com>]

Using HttpClient 2.0
JDK 1.4.2_04 on Fedora

Is there anything special that I have to do to make use of persistent 
HTTP(S) connections with HttpClient other than using 
MultiThreadedHttpConnectionManager ?

Basically, what I am doing is the following ( more explanation after the 
snippet of the source code ):

    MultiThreadedHttpConnectionManager connectionManager =
      new MultiThreadedHttpConnectionManager();
    connectionManager.setConnectionStaleCheckingEnabled( true );
    connectionManager.setMaxConnectionsPerHost( 10 );
    connectionManager.setMaxTotalConnections( 100 );

    this.httpClient = new HttpClient( connectionManager );
    this.httpClient.setConnectionTimeout( 30000 );
    this.httpClient.setTimeout( 30000 );

.... and then within a thread, the thread does this:

      String content;
      HttpMethod method;
       ....
    try {
      method = new PostMethod( connectionURL );
    
      method.setDoAuthentication( true );
      method.setRequestHeader( "Content-Type", contentType + "; 
charset=" + this.outboundEncoding);
      if( method instanceof PostMethod ) {
                PostMethod postMethod = (PostMethod) method;
                postMethod.setRequestBody( content );
      }
       int responseCode = this.httpClient.executeMethod( method );
       String response = method.getResponseBodyAsString();
       .....
    }
    catch( Exception ex ) {}
    finally {
       if( method != null ) method.releaseConnection();
    }


What I am doing, then, from a JUnit test class, is:

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) Send another HTTP POST to the same URL.

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_ .
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
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: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

Re: Persistent HTTPS connections

["Jesus M. Salvo Jr." <je...@migasia.com>]

Jesus M. Salvo Jr. wrote:

> 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 ?


What I have done now is, if I get a HttpRecoverableException, I retry 
the HTTP call.
The executeMethod() is therefore in a while loop. I am now to put a hard 
limit on the number of retries.
Just like to ask what have everyone else doing.
Is this the "best pratice" with HttpClient to handle persistent 
connections ?



Regards,

John


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

Re: Persistent HTTPS connections

["Jesus M. Salvo Jr." <je...@migasia.com>]

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: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org