Running applicationStop() from a thread immediately removes the application scope for all other running request threads.
I was investigating the potential use of applicationStop() to force onApplicationStart() to run on next page request so we could ensure single-threaded access when setting up application-scope stuff (eg. effectively an application "refresh").
I found Adam Cameron's blog entry (from 2012): http://blog.adamcameron.me/2012/07/investigation-into-applicationstop.html
He identifies this same issue with applicationStop() on ACF 10, but upon further testing he finds it's been fixed in ACF 10, and the long-running request thread maintained access to its application scope during the request.
I've run Adam's test code on Railo 4.2 and now Lucee 188.8.131.52 and found the same issue - applicationStop() removes the application scope from existing request threads that are also running at the same time.
In a production system, this renders applicationStop() unusable because you'd need to ensure there were no other requests running before calling it, otherwise they'd get errors.
Have I understood this correctly? Is there another way of forcing an application-scope refresh such that onApplicationStart() gets run single-threaded so we don't need locks?
I've analyzed this ticket a lot & confirmed the issue happening on lucee 184.108.40.206. I've just tried to access a variable in application scope inside a long running thread. In between, i just stopped the application using applicationStop(). It clears the application scope, which leads the long running thread end with undefined error. But it is working fine in ACF11. As we couldn't able to write test cases for this, I've just added sample application here in JIRA(LDEV0982.zip). Also i've added the stacktrace logged in thread.log file. Please check that too.
Steps for reproducing the issue:
first run thread.cfm.
Then run test.cfm immediately after running thread.cfm(within 15 seconds)
Error should be logged in \WEB-INF\lucee\logs\thread.log.