Details
Assignee
UnassignedUnassignedReporter
eric twilegareric twilegarLabels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
New
Details
Details
Assignee
Unassigned
UnassignedReporter
eric twilegar
eric twilegarLabels
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
Created 2 March 2022 at 22:07
Updated 3 March 2022 at 10:48
If Lucee is configured with the Lucee Queue either in the administrator or via LUCEE_QUEUE_ENABLE=true environment variables it correctly times out a request that is over the queue size and has been sitting in queue past the timeout value.
This option is awesome and is a far easier way to deal with load shedding then tomcat's maxThreads etc which is pretty confusing for when a server gets too many incoming requests and then starts to be unable to fulfill them.
When a request times out of the queue the request returns with a status code of 200 and content length of 0. This could however be a valid response from the server although unlikely that a request would have a content length of 0. In this way we can "detect" that we have hit this queue overload and retry the request or otherwise alert staff that we are filling the queues.
application.log does get a message to the effect of as below. With tools like splunk etc I can detect these and alert, but harder to drive things based on them.
application.log:"ERROR","http-nio-8888-exec-8","02/28/2022","10:24:47","controller","Concurrent request timeout (10) [10 ms] has occurred, server is too busy handling other requests. This timeout setting can be changed in the server administrator.;Concurrent request timeout (10) [10 ms] has occurred, server is too busy handling other requests. This timeout setting can be changed in the server administrator.;
This is driven by the logic in ThreadQueueImpl.java ~68
This then gets caught by CFMLEngingeImpl.java ~1212
which logs it to application.log
Then it returns a 200 with content length of zero which will get written to the tomcat access logs as such.
It would be nice if it would instead return a status code of 429 or a configurable status code so that upstream ( or is it downstream ) servers can react by either retrying the response or even better by scaling the fleet.
Thanks for you consideration. If the proper way to handle this would be to IOException to something like RequestQueueTimeoutException and catching like it is for RequestTimeoutException I could try to throw together a PR, but dealing with configuration and setting a status code in this part of the code is not clear to me.