In terms of the connection, the client sends a FIN but the server does not respond. That puts it into CLOSE_WAIT until the worker has eventually started and completed the request. As far as the application can tell, the response writer is still open when it's finally served, and doesn't throw when writing/flushing, so I cannot detect the situation there. Thanks, James -----Original Message----- From: undertow-dev-bounces(a)lists.jboss.org <undertow-dev-bounces(a)lists.jboss.org&gt; On Behalf Of James Howe Sent: 27 February 2020 21:48 To: undertow-dev(a)lists.jboss.org Subject: [undertow-dev] Worker queue timeout Under load, when the worker threads are saturated, new requests will be queued. Is there a way to timeout these requests, so that it doesn't waste time serving them later when the client has already given up? I saw a reference to RequestLimitingHandler having a configurable timeout, but that doesn't appear to be true. I also don't want any limit to how many request that can be waiting, only how long they can wait. This doesn't seem to be a feature offered by any of the standard Java ExecutorService implementations, but perhaps Undertow has added this (or an appropriate extension point for this) somewhere? Thanks James _______________________________________________ undertow-dev mailing list undertow-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/undertow-dev

That looks like a good solution, but not having any Kotlin in our build yet I'm hesitant to use it. It's also not clear from the email chain exactly how you schedule an additional task when a request is accepted/queued, especially if you don't have Kotlin Extensions available. I came up with a higher-level solution: - add X-Received-Time header to request in forward proxy / load balancer - add servlet filter to check header and sendError(503) if it exceeds the configured timeout (though in my case the client will never receive this) It seems like there's still a core bug of not reacting to the client-side close though. Thanks, James From: Stan Rosenberg <stan.rosenberg(a)acm.org&gt; Sent: 28 February 2020 19:18 To: James Howe <jmh205(a)cam.ac.uk&gt; Cc: undertow-dev(a)lists.jboss.org Subject: Re: [undertow-dev] Worker queue timeout On Thu, Feb 27, 2020 at 4:47 PM James Howe <jmh205@cam.ac.uk<mailto:jmh205@cam.ac.uk>> wrote: Under load, when the worker threads are saturated, new requests will be queued. Is there a way to timeout these requests, so that it doesn't waste time serving them later when the client has already given up? If I understand correctly, the same issue was discussed in this thread: https://lists.jboss.org/pipermail/undertow-dev/2018-July/002231.html We ended up implementing custom logic based on CAS; here is the snippet in kotlin: https://gist.github.com/srosenberg/ed8d71d2f68379f909b1c4b8343807aa Thus, if a request takes longer than requestTimeoutMillis to service, the exchange is ended with StatusCodes.REQUEST_TIME_OUT The performance overhead of CAS was negligible. Best, stan P.S. Sorry for the duplicate; first attempt to post was rejected by list server because I used the wrong reply address.