hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brooks, Kenneth S" <kenneth.s.bro...@chase.com>
Subject RE: stale connection
Date Wed, 12 May 2010 02:04:44 GMT
We are doing serialization over http..
This means that 100% of our calls will *not* be idempotent.. 

I don't see how we can avoid the stale check. 
Are you saying that NoHttpResponseException is __always__ safe to retry?

I can't take the risk of having a transaction submitted twice.. 

-k

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Tuesday, May 11, 2010 4:50 PM
To: HttpClient User Discussion
Subject: Re: stale connection

On Tue, 2010-05-11 at 12:28 -0700, Ken Krugler wrote:
> On May 11, 2010, at 11:53am, Brooks, Kenneth S wrote:
> 
> > In the 4.0.1 tutorial I see the following paragraph.
> >
> > ... begin snippet ...
> > HttpClient tries to mitigate the problem by testing whether the  
> > connection is 'stale', that is no longer valid because it was closed  
> > on the server side, prior to using the connection for executing an  
> > HTTP request. The stale connection check is not 100% reliable and  
> > adds 10 to 30 ms overhead to each request execution. The only  
> > feasible solution that does not involve a one thread per socket  
> > model for idle connections is a dedicated monitor thread used to  
> > evict connections that are considered expired due to a long period  
> > of inactivity. The monitor thread can periodically call  
> > ClientConnectionManager#closeExpiredConnections() method to close  
> > all expired connections and evict closed connections from the pool.  
> > It can also optionally call  
> > ClientConnectionManager#closeIdleConnections() method to close all  
> > connections that have been idle over a given period of time.
> > ... end snippet ...
> >
> > Today we implement both the stale connection checking as well as the  
> > IdleConnectionTimeoutThread (in 3.1).
> > I would love to save the 10-30ms overhead but without doing that  
> > stale check it is possible that a connection was closed (that the  
> > Idle monitor may not have awoken to catch)..
> > Sounds like to me the only way to be as close to 100% safe is to  
> > implement both..
> >
> > Is that correct?
> 
> I don't believe so.
> 
> Assuming the connection is stale, then you'll get an exception when  
> you try to use it, so assuming you have a retry handler installed, you  
> can automatically retry that type of failure.
> 
> Some code from the Bixo project to illustrate:
> 
>              _httpClient = new DefaultHttpClient(cm, params);
>              _httpClient.setHttpRequestRetryHandler(new  
> MyRequestRetryHandler(MAX_RETRY_COUNT));
> 
> 
>      private static class MyRequestRetryHandler implements  
> HttpRequestRetryHandler {
>          private int _maxRetryCount;
> 
>          public MyRequestRetryHandler(int maxRetryCount) {
>              _maxRetryCount = maxRetryCount;
>          }
> 
>          @Override
>          public boolean retryRequest(IOException exception, int  
> executionCount, HttpContext context) {
>              if (LOGGER.isTraceEnabled()) {
>                  LOGGER.trace("Decide about retry #" + executionCount  
> + " for exception " + exception.getMessage());
>              }
> 
>              if (executionCount >= _maxRetryCount) {
>                  // Do not retry if over max retry count
>                  return false;
>              } else if (exception instanceof NoHttpResponseException) {
>                  // Retry if the server dropped connection on us
>                  return true;
>              } else if (exception instanceof SSLHandshakeException) {
>                  // Do not retry on SSL handshake exception
>                  return false;
>              }
> 
>              HttpRequest request =  
> (HttpRequest)context.getAttribute(ExecutionContext.HTTP_REQUEST);
>              boolean idempotent = !(request instanceof  
> HttpEntityEnclosingRequest);
>              // Retry if the request is considered idempotent
>              return idempotent;
>          }
>      }
> 

Yep, a retry handler is the way to go. 

Oleg

> 
> --------------------------------------------
> Ken Krugler
> +1 530-210-6378
> http://bixolabs.com
> e l a s t i c   w e b   m i n i n g
> 
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org


This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.
Mime
View raw message