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
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
From: Stan Rosenberg <stan.rosenberg(a)acm.org>
Sent: 28 February 2020 19:18
To: James Howe <jmh205(a)cam.ac.uk>
Subject: Re: [undertow-dev] Worker queue timeout
On Thu, Feb 27, 2020 at 4:47 PM James Howe
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:
We ended up implementing custom logic based on CAS; here is the snippet in kotlin:
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.
P.S. Sorry for the duplicate; first attempt to post was rejected by list server because I
used the wrong reply address.