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 opc.getHttpServletRequest().getRemoteAddr().
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.
Just upgrades to firstname.lastname@example.org+120, with Java 11.0.19_7.
I’m seeing the logging for this:
downgrade priority of the a request at path: /app/path.cfm. Open locks at this time [a73a1076-c1fa-4cea-8b15342ba3f25a6f, c35ff6b0-39d1-41d9-8d592a90f0271b75].;java.lang.Throwable;java.lang.Throwable
It’s then followed by a full stack trace every time:
at email@example.com/java.lang.Thread.sleep(Native Method)
actually it is expected, when you bump the log level up to INFO, ERROR is the default
the idea being that it’s better that Lucee expresses (i.e. logs) what it has always done (since forever) with long running threads, which is downgrading the priority of any request running longer than 10s