Re: What does an http connector's idleTimeout actually do?

[Camille Fournier]

If it helps, the code is checking to see if the socket is open, if input or output on the socket has been shutdown, and if it's managed to flush the last bits. I think that by sleeping inside a handler you haven't closed the socket it in the way that the idle timeout will impact. It's behaving more like a garbage collector for half-closed sockets than something that times out requests that run too long. 

C

On Fri, May 13, 2016 at 8:59 AM, Matt Hurne <ma...@thehurnes.com> wrote:

I realize this is probably a Jetty question and the answer isn't Dropwizard-specific, but I'm hoping someone on this list can and won't mind answering it for me regardless...

What does an http connector's idleTimeout do? I thought I understood the documentation, but I'm not seeing the behavior I expected from a simple test. I enabled some debug logging and see that Jetty is deciding to ignore the timeout when it expires.

I'm using Dropwizard 0.9.2. Here's my config:

server:

  applicationConnectors:

    - type: http

      port: 8700

      idleTimeout: 1 second

  adminConnectors:

    - type: http

      port: 8701

logging:

  loggers:

    "org.eclipse.jetty.io.IdleTimeout": DEBUG

    "org.eclipse.jetty.io.AbstractEndPoint": DEBUG

    "org.eclipse.jetty.io.SelectChannelEndPoint": DEBUG

Here's the resource I'm testing with (this is Groovy):

@Path("/sleep")

class SleepResource {

    private AtomicInteger count = new AtomicInteger(1)

    @GET

    @Path('/{duration}')

    @CacheControl(noStore = true)

    String test(@PathParam('duration') Long durationSeconds) {

        def duration = Duration.seconds(durationSeconds)

        println "sleeping for ${duration} ${count.getAndIncrement()}"

        sleep(duration.toMilliseconds())

        return "done sleeping for ${duration}!"

    }

}

And my request:

➜  ~ curl -X GET http://localhost:8700/sleep/60

done sleeping for 60 seconds!

The following is logged repeatedly during the sleep, apparently once per second:

DEBUG [2016-05-10 14:12:25,686] org.eclipse.jetty.io.IdleTimeout: SelectChannelEndPoint@7323a6aa{/0:0:0:0:0:0:0:1:52049<->8700,Open,in,out,-,-,1005/1000,HttpConnection}{io=0,kio=0,kro=1} idle timeout check, elapsed: 1005 ms, remaining: -5 ms

DEBUG [2016-05-10 14:12:25,686] org.eclipse.jetty.io.IdleTimeout: SelectChannelEndPoint@7323a6aa{/0:0:0:0:0:0:0:1:52049<->8700,Open,in,out,-,-,1005/1000,HttpConnection}{io=0,kio=0,kro=1} idle timeout expired

DEBUG [2016-05-10 14:12:25,686] org.eclipse.jetty.io.AbstractEndPoint: Ignored idle endpoint SelectChannelEndPoint@7323a6aa{/0:0:0:0:0:0:0:1:52049<->8700,Open,in,out,-,-,1005/1000,HttpConnection}{io=0,kio=0,kro=1}

Given the fact that my resource method didn't write anything to the connection while it was sleeping, I expected the idleTimeout to kick in somehow...with a closed connection, a 5xx response, or something similar. But clearly Jetty is deciding to ignore the timeout. Why? And when wouldn't it do so?

Thanks,

Matt

--
You received this message because you are subscribed to the Google Groups "dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dropwizard-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matt Hurne]

Thanks, Camille, that does help.

I was surprised by this behavior because the last time I dealt with idle timeouts I was working with Dropwizard 0.6.2. I just ran this same test with that release and http.maxIdleTime set less to the sleep time, and sure enough, Dropwizard/Jetty closed the connection on the client after the duration specified by the http.maxIdleTime (before the sleep finished). In 0.6.2, the timeout behavior appears to depend on the type of connector used; BlockingChannelConnector is the default. If I specify "http.connectorType: nonblocking" with 0.6.2 so that it uses a SelectChannelConnector, I observe behavior similar to what I described for 0.9.2.

In 0.9.2, the connector used is a ServerConnector which uses a SelectChannelEndPoint. I don't see a way to configure 0.9.2 to use a different type of Connector nor a different type of EndPoint, so I'm assuming the behavior of idleTimeout in 0.9.2 can't vary the way it did in 0.6.2.

All of that said, I'm thinking the documentation for the idleTimeout configuration property needs improvement, though unfortunately I'm not sure what it *should* say. What do you think?

Thanks,

Matt