[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
