hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPASYNC-39) SocketTimeoutException occurs too soon
Date Thu, 20 Jun 2013 11:01:21 GMT

    [ https://issues.apache.org/jira/browse/HTTPASYNC-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689136#comment-13689136
] 

Oleg Kalnichevski commented on HTTPASYNC-39:
--------------------------------------------

You have a pool connections that time out after 5 seconds of inactivity, which is quite aggressive.
A connection can timeout immediately after being leased from the pool before any i/o on the
underlying channel resets the 'last used' value. This is similar to connection being shut
down by the opposite endpoint while the client is in the process of using it to submit a new
request. This problem is inherent in the nature of HTTP persistent connections and cannot
be fully avoided. There are ways to mitigate it, though, for instance, by disabling socket
timeout upon releasing connection back to the pool. BasicNIOConnPool does not do it out of
the box. If you think this is wrong, feel free to raise an enhancement request. But the problem
you are having has nothing to do with the original report and strictly speaking is not even
a defect.

Oleg
                
> SocketTimeoutException occurs too soon
> --------------------------------------
>
>                 Key: HTTPASYNC-39
>                 URL: https://issues.apache.org/jira/browse/HTTPASYNC-39
>             Project: HttpComponents HttpAsyncClient
>          Issue Type: Bug
>    Affects Versions: 4.0-beta3
>            Reporter: Clinton Nielsen
>         Attachments: log_stdout.txt, log.txt
>
>
> In a highly concurrent environment, where SocketTimeout is set to 30,000 milliseconds,
we are often seeing a timeoutexception after only 0 or 1 or 2 milliseconds has actually passed.
> I get the impression that in the AbstractIOReactor timeoutCheck function, session.getLastAccessTime
is being called on the session before the lastAccessTime is set on the session for the current
session (ie. the lastAccessTime being retrieved is the time that was set on the session object
for the previous http session)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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


Mime
View raw message