@micstriit has been working on a new feature which will help to make uncoordinated DDOS attacks less effective against Lucee, by amongst other things reducing the thread priority
It’s been added to the 188.8.131.52-SNAPSHOT and 184.108.40.206-SNAPSHOTs
More details in the ticket [LDEV-4123] - Lucee
Interesting… two things here:
I’m most curious about the comment about it doing this priority reduction
Same way Lucee reduces prio of threads running more than 10 seconds.
Regarding thread deprioritization of an active long-running thread, am I inferring correctly that a long running database transaction thread with a mutually exclusive lock would become a liability (blocker) for other higher priority (normal) threads that want to read committed data and MUST wait?
More info on how that works may answer my question better (or tests related to that feature where I can add my DB related scenarios)
In the code I see
Can someone remind me how this is handled when being served via proxy (or load balancer)?
I think this effectively reduces the concurrent request count for processing at normal priority, no?
First of all the feature that Lucee/Railo reduces the priority always existed, that was never added because already Railo 1.0 had it.
This feature of course is limited to code executed within the JVM, of course when you do a db query, the DB server does not care about this setting.
We did of course consider different ways to identify a client, cookies of course is not a solution because with a DOS attack you mostly not get a cookie back. We are of course open for suggestion to improve this. Have in mind that this setting never blocks a client, it only slows them down.
I appreciate the reply; I’m not at all saying this is bad behavior per se …
This question was a sub-par caffeine level contrived (fake) scenario where a known longer-running task (like a nightly task / update) may unintentionally block other requests longer due to the reduced priority scenario.
- Even databases will pause thread execution of a query to process other query requests if concurrency is possible - so it’s not a bad thing for Lucee to do a similar thing.
In the end: Knowing there’s this 10 sec window specifically makes me want to re-think some of our external resource fetches where we already have a limited resource that specifically relies on FIFO (first request in, first request out) processing.
I appreciate having the better understanding of what’s actually happening behind the scenes (and if I can specify a request-priority level outside of an un-joined thread) for future improvements.
We’re going to add some logging around both these behaviours too
Update @micstriit just added some