One thing you could do is use the Enterprise edition of cold fusion. I believe that this version runs each "customer" as a separate daemon. This could provide you with the robustness you need while not spening a lot of time hunting down malicious CFML code.
I agree that the fact that the cold fusion daemon restarts because of Bad code is a big problem. We had an issue here recently where a Schedule task that was set to run every five minutes started failing. This caused the Daemon to RESTART every five minutes wreaking havoc on the Sessions this machine was maintaining. It seems rather silly to restart a whole daemon because one scheduled task failed on some trivial datasource error. Of course, as always there are work arounds. One: don't use sessions variables. Two: single thread execution, etc. etc. the fact remains that I think this is causing problems for a lot of people. Sincerely, Leon Oosterwijk ISDN-NET Inc. www.isdn.net +1 615-221-4200 > -----Original Message----- > From: Mark Leonard [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 3:17 PM > To: CF-Linux > Subject: RE: cfserver getting sig 11. > > > > I think you are getting confused about threads and children. > > > In Linux, threads are sort-of processes. They have a pid > (and show up > > in ps, yuk!), but they are not really separate processes. > They share > > the same address space. > > Hold on a second. What Chad has found is the following: if > one thread dies, it causes the daemon to die. > > Having done a fair bit of thread programming myself, this > does not make sense. A thread (child) should have enough > intelligence in order to detect a problem WITHOUT causing or > signalling the daemon (parent) to die. Concurrency issues > don't exist in the case of tracking threads - only the treads > themselves ever need to report (write) their status, and the daemon > (parent) is the only entity that should ever need to see > (read) the status of the threads. > > Anyway, this is getting way off topic. > > The problem of sig11/sig6 restarts still remains. If Chad > has not yet provided sufficient information for you to > diagnose the problem, then let us know. > > > You will probably not be able to diagnose your problems > 'from below' > > as you are trying to do. You will probably need to examine your > > ColdFusion CFML application. > > We have over 12,800 CFML files on this particular server. > Many of which are provided directly by our clients. This > machine hosts over 200 clients. In order to avoid the > locking issues that ColdFusion seems to have, we have enabled > single-threaded sessions. > > If the problem truly is bad CFML, why is the daemon not > reporting the suspect file? Furthermore, how and WHY would > bad markup cause a daemon to die? > > I look forward to your reply. > > ______________________________________________________________________ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm ------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/cf-linux%40houseoffusion.com/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_linux or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
