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] Resolved: (HTTPCORE-149) read timeouts do not respect start of request
Date Sat, 01 Mar 2008 14:00:56 GMT

     [ https://issues.apache.org/jira/browse/HTTPCORE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kalnichevski resolved HTTPCORE-149.
----------------------------------------

    Resolution: Fixed

Hi David,

I made changes to ensure that either a read or write operation results in a reset of the timeout
counter. This should pretty much take care of the problem in my opinion. Please let me know
if you find this solution satisfactory.

Oleg

 

> read timeouts do not respect start of request
> ---------------------------------------------
>
>                 Key: HTTPCORE-149
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-149
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore
>    Affects Versions: 4.0-alpha6
>         Environment: OSX 10.5.2
> java version "1.5.0_13"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
> Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
>            Reporter: David Koski
>             Fix For: 4.0-beta2
>
>
> This code in BaseIOReactor
>     protected void timeoutCheck(final SelectionKey key, long now) {
>         Object attachment = key.attachment();
>         if (attachment instanceof SessionHandle) {
>             SessionHandle handle = (SessionHandle) key.attachment();
>             IOSession session = handle.getSession();
>             int timeout = session.getSocketTimeout();
>             if (timeout > 0) {
>                 if (handle.getLastReadTime() + timeout < now) {
> is looking at the last read time.  This will be the creation of the connection (if new)
or the last time the session was used, if a keepalive connection.  If what you connect to
has relatively high idle times on its keepalive connections (say 60s) and you submit a request
against it after it has been idle for 15 seconds, you lose 15 seconds off your actual timeout.
> For example, in my submitRequest:
>         public HttpRequest submitRequest(final HttpContext context) {
> i set the read timeout on a per request basis:
>                 if (timeout != null) {
>                     connection.setSocketTimeout((int) timeout.getReadTimeout());
>                 }
> to, e.g. 120 s.  My request is for this cgi:
> #!/bin/sh
> echo "content-type: text/plain"
> echo ""
> sleep 110
> ls
> If I use an existing session, this typically times out because it counts from the last
read from the request.
> Further evidence, if I have the session and I reset the last read time in submitRequest(),
it works correctly:
>                 try {
>                     final Field field = session.getClass().getDeclaredField("key");
>                     field.setAccessible(true);
>                     final SelectionKey key = (SelectionKey) field.get(session);
>                     final SessionHandle handle = (SessionHandle) key.attachment();
>                     handle.resetLastRead();
>                 } catch (final Exception e) {
>                     log.debug("unable to access key", e);
>                 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message