Have you ever seen SleeperThreadAborting messages in a message log? Do you know what they mean and why they appear? This week I’ll attempt to clear up some confusion and in the process help you improve your Millennium performance.
SleeperThreadAborting messages are created by the CPM Script server when it detects that a script is taking too long to execute. It detects this by spawning a “sleeper thread” prior to executing the script. If the script takes too long, the sleeper thread “wakes up,” writes the SleeperThreadAborting message into the log file and kills itself so that the system will start a new instance of CPM Script.
This may sound bad, but it really is an excellent way to protect the entire system from long-running scripts. The key to this behavior is the KillTime property of the server’s configuration. Its default setting is 2, meaning that the sleeper thread will wake in two minutes if the script has not been completed.
In the normal course of a week, a hospital might expect to get a few SleeperThreadAborting messages in the message log file for CPM Script. It might happen, for example, when a user searches for too broad a scope of patients. So I was curious when, at a recent client visit, I noticed that there were no SleeperThreadAborting messages logged. A search into the server’s properties showed that the KillTime property was set to 30, meaning that CPM Script could take up to 30 minutes to execute a script before getting killed. (Concerning last week’s blog, under no circumstances should SleeperThreadAborting appear in your messages.suppress file.)
Why is a longer setting a problem, especially since it provided enough time for the scripts to be executed? Imagine sitting at your computer and waiting 30 minutes for an hourglass to go away. Nobody does that. The user aborts the command that caused the slowdown and either tries again or looks into the problem. With Millennium, if the user closes the application because a script is taking too long, the CPM Script server continues to execute the script until the script completes or the KillTime setting is reached and the sleeper thread aborts the process. That’s why the KillTime default is 2. Longer times waste system resources and create a bottleneck by consuming an instance of your CPM Script server.
So how do you resolve issues where scripts take more than the default kill time?
1. Examine the SleeperThreadAborting messages to determine if a specific script or user is causing the issues.
- Verify that the scripts are performing as expected. Contact your vendor if necessary.
- Verify that users have not provided parameters that cause scripts to run for a long time. If they have, additional training might be needed.
2. If the script is performing as expected and you do not have a training issue, you can use what is known as “request class routing” to specify that certain requests get routed to specific services. See your Cerner documentation on how to set up request class routing for your version of Millennium. What this will do is route only the specified requests to special CPM Script instances where the KillTime property has been set to a more appropriate value.
Prognosis: Setting a proper kill time for the CPM Script server and routing specific scripts via request class routing ensures that your system will effectively protect itself from long-running scripts and provide better overall response times to the end user.