The ColdFusion MX error message "Request timed out waiting for an available thread to run" occurs specifically when a thread in the queued request pool times out while still in the queue, before it ever had a chance to make it to the running request pool. This blog entry revisits a topic previously blogged about here.
An example of the Java stack trace for the exception might look like this at the top: java.lang.RuntimeException: Request timed out waiting for an available thread to run. You may want to consider increasing the number of active threads in the thread pool.
at jrunx.scheduler.ThreadPool$Throttle.enter(ThreadPool.java:116)
at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:425)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
The helpful hint provided in the exception message suggests increasing the active thread pool size, which would correspond to the Simultaneous Requests setting in the ColdFusion Administrator. While that might be a short term band-aid to the problem, in most cases this will simply delay the onset of the symptoms rather than truely solve the problem.
To back up for a moment, I'll take a look at some of the settings in the JRun server's jrun.xml configuration file, found in the SERVER-INF directory for a given server instance. The threadWaitTimeout setting in jrun.xml controls how long a thread will wait in the queued request pool. The activeHandlerThreads setting is the same as the Simultaneous Requests setting in the CFAdmin, and this setting is the maximum size of the running request pool, or the maximum of how many actual requests could be actively processed at any given moment. The maxHandlerThreads is the maximum total thread limit as a sum of the running request pool size (activeHandlerThreads) plus the maximum allowed queued threads (which can be restated at the maxiumum number of queued threads is equal to maxHandlerThreads - activeHandlerThreads).
If you're getting this error, then the problem is most likely bottleneck requests that are shifting the throughput rate downward so that more threads are added to the queued request pool than can be reasonably processed by the running request pool. It's not necessary that the running request pool is completely occupied with bottleneck threads, but just enough of them to cause a noticeable increase in current number of threads in the queued request pool. This doesn't necessarily mean that the queued request pool has reached its maximum size, but just that the threads in the queued pool weren't getting a chance to run within the threadWaitTimeout period.
To better diagnose the problem, try to find out what's in the running request pool. I recommend taking a series of three thread dumps about 15-30 seconds apart at the time this error is being reported, and then looking for differences between the running threads across the span of the three thread dumps to identify any that might be 'stuck' on something. The running threads are usually identifiable by having a 'jrpp-' to the thread id number and a reference to one of your application templates in the stack such as those with a .cfm or .cfc extension.
Related entries:
Related Blogs:
|
