You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Michael Moores <a-...@expedia.com> on 2015/01/16 21:29:11 UTC

Question about application layer timeout vs. socket timeout

I am seeing a situation where the HTTP transaction looks hung if I
experience a 
degraded network.  If the HTTP response data comes back very slowly the
socket timeout never gets triggered and
the thread can remain hung up.  I verified this with a quick test,
controlling the server socket data rate.

Is there a way in version 4.3.6 to ensure that the connection socket gets
shutdown if this happens?
I don¹t see that closeIdleConnections/closeExpiredConnections would help
when the connection is leased.

I am using PoolingHttpClientConnectionManager/CloseableHttpClient.
What I need is an application layer timeout rather than a data link layer
timeout.

Thanks,
Michael





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


Re: Question about application layer timeout vs. socket timeout

Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2015-01-16 at 20:49 +0000, Michael Moores wrote:
> Following up - maybe what I should do to implement a hard timeout is
> execute the request on a separate thread and if this thread is taking
> longer than the configured SO timeout I can call the abort() method on the
> HttpUriRequest object.
> Would that be my best choice?
> 
> 

Yes, it is. 

The feature you want is called 'request deadline'. For details see:

https://issues.apache.org/jira/browse/HTTPCLIENT-1074

Oleg

> 
> On 1/16/15, 12:29 PM, "Michael Moores" <a-...@expedia.com> wrote:
> 
> >I am seeing a situation where the HTTP transaction looks hung if I
> >experience a 
> >degraded network.  If the HTTP response data comes back very slowly the
> >socket timeout never gets triggered and
> >the thread can remain hung up.  I verified this with a quick test,
> >controlling the server socket data rate.
> >
> >Is there a way in version 4.3.6 to ensure that the connection socket gets
> >shutdown if this happens?
> >I don¹t see that closeIdleConnections/closeExpiredConnections would help
> >when the connection is leased.
> >
> >I am using PoolingHttpClientConnectionManager/CloseableHttpClient.
> >What I need is an application layer timeout rather than a data link layer
> >timeout.
> >
> >Thanks,
> >Michael
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
> 



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


Re: Question about application layer timeout vs. socket timeout

Posted by Michael Moores <a-...@expedia.com>.
Following up - maybe what I should do to implement a hard timeout is
execute the request on a separate thread and if this thread is taking
longer than the configured SO timeout I can call the abort() method on the
HttpUriRequest object.
Would that be my best choice?



On 1/16/15, 12:29 PM, "Michael Moores" <a-...@expedia.com> wrote:

>I am seeing a situation where the HTTP transaction looks hung if I
>experience a 
>degraded network.  If the HTTP response data comes back very slowly the
>socket timeout never gets triggered and
>the thread can remain hung up.  I verified this with a quick test,
>controlling the server socket data rate.
>
>Is there a way in version 4.3.6 to ensure that the connection socket gets
>shutdown if this happens?
>I don¹t see that closeIdleConnections/closeExpiredConnections would help
>when the connection is leased.
>
>I am using PoolingHttpClientConnectionManager/CloseableHttpClient.
>What I need is an application layer timeout rather than a data link layer
>timeout.
>
>Thanks,
>Michael
>
>
>
>