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@acm.org>
Sent: 28 February 2020 19:18
To: James Howe <jmh205@cam.ac.uk>
Cc: undertow-dev@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> 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.