2
Replies
Thanks for your comments Adam. A lot of work went in to that post. Our client is a high-profile high-traffic Australian site, so at times I have the luxury of having the time to spend on complex issues. It would me much appreciated if you could leave a comment on the blog, it’s looking quite baron at the moment 
The one big thing I missed in my post was the system configuration (I’ll update the post in the morning when I get in to work)
Production configuration:
Windows Server 2003 32bit – IIS 6
Coldfusion 8.0.1 (no hotfixes) 8,0,1,195765 ,Enterprise, Multiserver
JRun connector is configured per-site
JDK 1.6.0_17
Xeon 2 core + Hyperthreading ( > 1 year old)
- this is the machine where it occurs naturally
Development machine
Windows 7 x64
Coldfusion 8.0.1 (tested with and without hotfix 4) 8,0,1,195765 ,Enterprise, Multiserver x64
Jdk 1.6.0_17 x64
IIS 7
JRun connector is configured per-site
Core 2 duo
- this machine replicated the problem with the production code and also the synthetic example
After reading your post I retested using the JDK shipped with ColdFusion (1.6.0_4) and I could still replicate the problem.
SeeFusion is installed on both configurations. Removing this locally still produced the problem
Template Cache is off on both machines, turning it on still produced the deadlock, although I would suggest having it off to better match our configuration.
There are some bugs in the JMeter test I supplied. The ThreadGroup for the templateCache node is set to run for 60 seconds, this should be 600 seconds to match the other 2 thread groups - although the deadlock should occur within 30 seconds. Also the CFM Request node has the server set to “cfdeadlock” this should be removed so it inherits the HTTP Request Defaults.
Finally, make sure you have set the correct password in clearTemplateCache.cfm
To easily detect the deadlock I use seefusion, when the request time is in the order of 5 to 60 seconds I know that it has deadlocked. If I manually request a page through a web browser the web browser just sits there loading. When it does deadlock JMeter does not show you anything to indicate a deadlock.
If you’re not running a multi-core machine this may be the issue.
After all that I assume it still won’t work for you, so we must look at the test it’s self.
While developing the synthetic test the number of classes (cfc’s) loaded by each request was an important factor. I had to increase the number of unique cfc’s created by the CFM request (14 at the moment) and the number of unique cfc’s returned by the various web service methods. With a low number of cfc’s the error did not happen. With a large number of cfc’s ColdFusion will be spending more time in the class loader, increasing the chances of a deadlock. I suspect that a larger number of cfc’s in the Web Service request will have a bigger impact then a large number in the CFM request, but you should still increase the number in both. I assume that simply creating the same cfc many times won’t work.
Good luck & keep me posted.
Cheers,
Aaron
AdChoices