hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Persistent HTTPS connections
Date Fri, 14 May 2004 07:17:52 GMT
John
No reason other than HttpMethod & HttpMethodBase being horrible
monstrosities badly in need of a compete redesign

Oleg


On Fri, 2004-05-14 at 09:02, Jesus M. Salvo Jr. wrote:
> One small thing though. Why is setMethodRetryHandler() defined in 
> HttpMethodBase class instead of the HttpMethod interface ?
> 
> 
> Jesus M. Salvo Jr. wrote:
> 
> >
> > Hi Oleg,
> >
> > Thanks for that. I have now implemented my own MethodRetryHandler and 
> > got rid of my custom loop / retry.
> > Cleaner log files for my application as well.
> >
> >
> > John
> >
> > Kalnichevski, Oleg wrote:
> >
> >> John,
> >>
> >> Please correct me if I am wrong (which may well be the case) 
> >> SO_TIMEOUT only affects socket read operations. I thought it had 
> >> nothing to do with SSL inactivity timeout. But it looks like it might.
> >>
> >> There's another way to deal with recoverable exceptions. You can 
> >> provide a custom implementation of MethodRetryHandler
> >>
> >> http://jakarta.apache.org/commons/httpclient/apidocs/org/apache/commons/httpclient/MethodRetryHandler.html
> >>
> >>
> >> The default implementation of the MethodRetryHandler is quite 
> >> conservative. It does not allow the method to be retried if the 
> >> request has been transmitted in its entirety.
> >> http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/DefaultMethodRetryHandler.html#62
> >>
> >>
> >> Oleg
> >>
> >>
> >> -----Original Message-----
> >> From: Jesus M. Salvo Jr. [mailto:jesus.salvo@migasia.com]
> >> Sent: Thursday, May 13, 2004 7:40
> >> To: commons-httpclient-dev@jakarta.apache.org
> >> Subject: Persistent HTTPS connections
> >>
> >>
> >>
> >> 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
> >>
> >>
> >> ***************************************************************************************************

> >>
> >> The information in this email is confidential and may be legally 
> >> privileged.  Access to this email by anyone other than the intended 
> >> addressee is unauthorized.  If you are not the intended recipient of 
> >> this message, any review, disclosure, copying, distribution, 
> >> retention, or any action taken or omitted to be taken in reliance on 
> >> it is prohibited and may be unlawful.  If you are not the intended 
> >> recipient, please reply to or forward a copy of this message to the 
> >> sender and delete the message, any attachments, and any copies 
> >> thereof from your system.
> >> ***************************************************************************************************

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


Mime
View raw message