I’ve just had a good conversation with one of the engineers at Fusion-Reactor, and in looking at my current server install he noticed a number of database threads that were stuck, notably with a “”ThreadDeath” error from the Lucee engine. He mentioned that ThreadDeath was a dangerous situation and that there is a fork of Lucee that doesn’t use it AND/OR a way to config to turn that off. Does anyone more knowledgeable than I (which would be everyone) have any thoughts on this? I should add that I’m using CommandBox and would REALLY like to continue using it rather than any kind of manual install of Lucee if at all possible!

@Peter Hoopes Yes, Lucee is aggressive in how it kills threads, but it also kills them in a way which can leave resources unaccounted for.

Yes, discussed it informally with FR team so semi-aware at least.

if you are hitting a problem like this, hammer out a minimal repo so it can be addressed

This was some time ago and after lengthy chats with Micha I believe both env vars added but also Lucee considerably refactored with its request timeouts. What version of Lucee was this running? And yes, we run with Lucee never attempting to detect timeouts and so never trying to kill threds.

It would be nice if there was a formal way of turning it off rather than mitigating in 6 as would like to get on to formal packages

Agreed. Or at least, have a setting to change Lucee to give up after it interrupts the thread and not continue on to a thread.stop() (which throws thread death error). Interrupting a thread is not nearly as effective in killing it, but an interrupted thread is at least allowed to finish cleaning up any resources. In the past, Micha has said that any thread killed will always clean up its resources, but I'm still not convinced of that. One not need look far on the internet to find a plethora of advice telling you never to use thread.stop() https://stackoverflow.com/questions/16504140/thread-stop-deprecated

Yes i remember back in the day a conversation with Alan Williamson of Open BD and Open BD never supported request time out as it was determined it could never be something 100% reliable

I think it's find so long as you stick to interrupts-- those are the recommended java way to tap a thread on the shoulder and politely ask it to go. Some CF tags and Java methods (like

sleep()

) will respond (raise an interrupted exception) to interrupts, but many CFML tags and constructs will never check if they've been interrupted so it has limited use. I've had to take care in checking things like this in CommandBox CLI, otherwise Ctrl-C would be of no use 🙂

yeah i mean the killing rather than the interrupting

Wow… that was a lot more than I expected and WAY over my head. 😳 I’m a medium level sys admin with Lucee and CB so I’m wondering… my best bet is to change the timeout setting for the particular CF pages that are affected, or is something I can/should change on this instance of CommandBox/Lucee? Or, figure out how to update the

lucee.async.request.handle

setting? I know I have some slow DB issues that I’m working on, but I’m also trying to avoid any particular Lucee/Java Thread issues.

Honestly, I wouldn't change that setting unless you have a specific issue you're trying to solve. Generally speaking • set your request timeout higher if possible • Keep an eye on long requests in FR so you can address them