Skip to content

Request timeout should be disabled once connection comes back to the pool #1109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
carryel opened this issue Mar 6, 2016 · 7 comments
Closed
Assignees
Milestone

Comments

@carryel
Copy link
Contributor

carryel commented Mar 6, 2016

I am using AHC v1.9.32 with grizzly provider(grizzly framework v2.3.24).

And major configuration is the following:

  • pooledConnectionIdleTimeout: 300000 (5min)
  • requestTimeout: 1000 (1sec)
  • allowPoolingConnections: true
  • allowSslConnectionPools: true
  • connectionTTL: -1

First, I expected http's idle-connection would be kept during 5min in pool but the connection would be always closed in about 1 sec.

When I debugged, grizzly provider used IdleTimeoutFilter with requestTimeout and the timeout was applied at the connection regardless of connection pooling. So the idle connection would be closed in requestTimeout.

Grizzly initializes the transport with IdleTimeoutFilter which has the request timeout.
When a connection has been established, the filter has the timer with FOREVER-timeout and the timer has the request timeout at next steps. When the connection has been closed, the filter resets the timer.

But if we use connection pool, the connection is not closed until pool's idle timeout. So when the connection will be returned to the pool, the request timeout should be disabled.

@oleksiys
Copy link
Contributor

oleksiys commented Mar 9, 2016

Could you pls. create a simple testcase?

@carryel
Copy link
Contributor Author

carryel commented Mar 9, 2016

@oleksiys
Sure. But.. AHC testcases can't get the client connection so you should test some manually. :-)

In PerRequestTimeoutTest.java, add the following testcase.

    @Test(groups = { "standalone", "default_provider" })
    public void testGlobalIdleTimeout2() throws IOException {
        final int requestTimeout = 10 * 1000; // Reproduced, after 10sec, connection was closed
        //final int requestTimeout = 30 * 1000; // connection was still ESTABLISHED
        try (AsyncHttpClient client = getAsyncHttpClient(
                new AsyncHttpClientConfig.Builder().setRequestTimeout(requestTimeout).build())) {
            for (int i = 0; i < 2; i++) {
                Future<Response> responseFuture = client.prepareGet(getTargetUrl()).execute();
                Response response = responseFuture.get();
                assertNotNull(response);
                assertEquals(response.getResponseBody(), MSG + MSG);

                System.out.println("#####Please watch your established port(" + port1 + ")");
                TimeUnit.SECONDS.sleep(15);
            }
        } catch (InterruptedException e) {
            fail("Interrupted.", e);
        } catch (ExecutionException e) {
            fail("Timed out.", e);
        }
    }
  1. Run this testcase with GrizzlyPerRequestTimeoutTest.
  2. Check ESTABLISHED port for a while. This test runs two requests with the same client. The same connection should be used without requestTimeout.

PS) NettyPerRequestTimeoutTest worked fine.

oleksiys pushed a commit that referenced this issue Mar 11, 2016
@oleksiys
Copy link
Contributor

@carryel could you pls. test it now?

@carryel
Copy link
Contributor Author

carryel commented Mar 11, 2016

@oleksiys Yes. It works fine. Thanks! [rev.088948a]

@carryel
Copy link
Contributor Author

carryel commented Mar 14, 2016

@slandelle Could I know the approximate release plan of AHC v1.9.34?

@slandelle
Copy link
Contributor

closed by 088948a

@slandelle
Copy link
Contributor

@carryel @oleksiys done

@slandelle slandelle modified the milestones: 1.9.34, 1.9.33 Mar 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants