Life of a thread

Question for when code runs longer than the request timeout.
We have noticed that the server seems to slow down. My hunch is long running queries or http requests.
Will adding timeout attributes help? Will the the thread die nicely?
Lucee Version:

Timeouts on queries and http requests will result in an error that you can catch (by wrapping said queries and http requests in try/catch)… or just let it fall through to produce an error. In either case the thread should die gracefully.

The better approach, however, is to install Fusion Reactor. Your hunch may be correct, or it may not. FR will tell you which requests (and which queries) run long. From there you can figure out why and optimize the code to perform better, or break long running code into a series of requests, threads or tasks, as deemed appropriate.

The slowdown you’re experiencing could also be due to lack of server resources, which FR will also be able to tell you, under load. Depending on load you may also be running up against request limits that are, effectively, queuing further requests - this can also show up as a ‘slow down’ effect, since requests are waiting in a queue to be served.

I’d start with FR in either case and then adjust as needed from there. Simply slapping timeouts on things is a blind approach which may, or may not, simply be wasted effort and is a bit of a gamble.


– Denny

Thanks, I looked at some of the requests while reproducing the issue reported from the client and traced it down to some http calls that would hang on a secondary application, which was hanging on some queries that would take a long time to return. Since the user didn’t know, they ended up clicking a button and generating lots of requests for the same scenario. Adding some timeouts to the areas seems to have improved it.

Ah, in that case you might want to disable the button with JS/jQuery once it has been clicked (typically on form submit) and set the button text to ‘Loading…’ or ‘Processing…’. This will prevent the multiple requests from firing and give feedback to the user that something is happening.


– Denny

Good advice, lots of people still double click on webpages, can cause all sorts of strange behaviors

Yeah that is one action we have taken to help prevent it in the future, but it wouldn’t have stopped everything, we could simulate the activity just by having 2-5 users generating the long running report, and starting threads to back up, which then would cause threads on the api request level from the original app to back up. The timeouts have helped, next will be to dig more into the session size to see if that is an issue as well, each session looks to be 5-15 MB of data. Going over an API creates many sessions and a very large memory imprint it looks like.

Another thing to think about if sessions are getting too big is off loading some of it to memcached, it always amazes me how fast (and reliable) memcached is and its also handy to be able to set the expiry time.
( by Jon Hirschi)