The problem is that the requests are performing native operations such as I/O socket activities. Java has a known limitation that a Thread Kill will not kill a thread that is currently performing native operations. FusionReactor first attempts to perform a softkill by asking the thread to die, and then tells the thread to die if this fails. Unfortunately even FusionReactor cannot overcome this limitation.
The reason this happens is that ColdFusion is sending data to the client which goes via a Socket. The socket performs native I/O, but if the client does not accept the request content then ColdFusion is unable to send any further data. This is can occur with a web browser for example when a dialog appear asking you if you want to save a file. If the user does not click Yes or No, the socket remains blocked the entire time trying to write the content. This thread cannot be killed. IE also has some issues that it sometimes keeps connections open even when the IE window has been shut. The iexplorer.exe is still running on the users PC but the user doesn't see it, and as a result can also keep these connections open.
Other solutions to using native thread kills have been researched, but they can make the OS instable and were advised not to do it by operating system vendors. However Sun do know of the limitation are are looking to improve Java possibly in the furture! In the current CF world this doesn't bring us much, but this problem isn't limited to CF, it's reported all over the web for every kind of J2EE server (unfortunately) and many Java apps too.
|Components:||Request Managment, Thread Management|
|Last Updated:||18/Jan/08 8:21 PM|
FRS-25: Why doesn’t soft kill always work? (Understanding Soft Kill Limitations)
FRS-102: Sometimes Crash Protection does not kill long running requests.
FRS-149: I’ve been using FR on a problem server, and the Crash Protection doesn’t seem to be very reliable. I have it set to kill any requests longer than 120 seconds, but most of the time it doesn’t!?
Comments are closed.