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 <[email protected]> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
