hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Koski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-149) read timeouts do not respect start of request
Date Fri, 29 Feb 2008 21:14:54 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573967#action_12573967

David Koski commented on HTTPCORE-149:

There are only two times it is set: on creation of a SessionHandle and in org.apache.http.impl.nio.reactor.BaseIOReactor.readable(SelectionKey).

The problem I run into is I manage a pool of these keepalive connections.  When I obtain one
and try to use it, the timeout I set is not the amount of time I allow for a request to be
processed (if the connection was brand new this would be true), but the time from the last
read from the connection.  If the server I connect to has a substantial keepalive timeout
(mine do), this might be a big difference in what I expect from the timeout I set vs what
I actually get.

> 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

View raw message