One thing along those lines, look for calls to cfx_ tags. Often these were not written with good memory management practices and I always lock calls to those also.
Kind Regards - Mike Brunt, CTO Webapper Blog http://www.webapper.net Web site http://www.webapper.com Downey CA Office 562.243.6255 AIM - webappermb Web Application Specialists -----Original Message----- From: Matthew Small [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 10:21 AM To: CF-Talk Subject: RE: Server Problems When Code is Not Locked (was RE: Application vari ables) You are trying to fix one problem at a time, and that's all you can do to pinpoint the problem unless there are firm indicators that the problem lies elsewhere. My opinion is that you're on the right track - but don't be surprised if there are other problems as well. You still have to fix these locking problems even if they aren't the main problem. Matthew Small IT Supervisor Showstopper National Dance Competitions 3660 Old Kings Hwy Murrells Inlet, SC 29576 843-357-1847 http://www.showstopperonline.com -----Original Message----- From: Haggerty, Mike [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 1:08 PM To: CF-Talk Subject: Server Problems When Code is Not Locked (was RE: Application vari ables) Here is a case study in the use of locks around session and application variables. Read on, at the end I have a few questions to the great minds and gurus of this list (especially Raymond Camden). The project I am working on right now is the rewrite of an application which never should have gone into production in the first place. The application was written three years ago and errors abound (common messages shown below): ----- Error Diagnostic Information unknown error condition unknown error while executing a tag ----- Or: ----- Request cancelled or ignored by serverServer busy or unable to fulfill request. The server is unable to fulfill your request due to extremely high traffic or an unexpected internal error. ----- We see at least 50 of these in the application log daily, much more around election time when traffic skyrockets. Every once in a while I also see a PCode error, but I don't have the syntax in front of me. The app runs on NT 4 with CF4.5 and makes extensive use of application and session variables. By extensive, I mean it has large structures contained in the application scope and calls data from them 10 - 80 times per page. I looked at the CPU usage for Cold Fusion to determine the total amount of data in the application scope, and saw it go up from about 30000k to 89000k just when the application loads. So there is a lot of data, but that should not be a big issue - the app is running on a pretty powerful server. The challenge, it would seem, is to have the code access the data properly. The code possesses no locks anywhere (!). What I am doing is exclusively locking all of the application and session variables when they are set, and putting readonly locks around these variables whenever they are read. My code looks like this: <cflock scope="session" type="readOnly" timeout="10"> <cfif NOT isdefined("application.regional_development_orgs")> <cfset needs_init = 1> </cfif> </cflock> <cfif needs_init eq 1> <cflock name="data_detailed_smobe_data" throwontimeout="Yes" timeout="10" type="EXCLUSIVE"> <cfset temp = structNew()> <cfloop from="1" to="#listlen(application.state_names_list)#" index="dex"> <cfset temp2 = structInsert(temp, listgetat(application.state_names_list, dex), "")> </cfloop> ... do more stuff ... <cfset application.regional_development_orgs = structCopy(temp)> <cfset needs_init = 0> </cflock> </cfif> I am taking the entire session scope and setting it to a request variable at the top of every page, and calling these request variables when needed (doing it this way...): <cflock scope="session" type="readonly" timeout="20"> <cfset request.session = structCopy(session)> </cflock> <cfoutput>#request.session.state_name#</cfoutput> Calling variables from the request scope instead of session I am doing something similar with application variables by putting specific structures in the request scope on pages where they are used, a la: <cflock scope="SESSION" type="READONLY" timeout="20"> <cfset request.senate_demographic_data = structCopy(application.senate_demographic_data[request.session.state])> </cflock> <cfoutput>#request.senate_demographic_data[request.session.state_name][" min_ bus"]#</cfoutput> Calling variables from the request scope instead of application My question is, does it sound like I am addressing the core problem or am I just enhancing the code? Could the real problem be with the amount of data in the application scope, or is there something else I am not thinking of? Does anyone have any advice on how to pinpoint the exact cause of the problems I am running into (or have any experience with applications using this much data in shared memory)? Am I writing these locks as efficiently as possible? Should I be thinking about working with my sysadmin to fine-tune the server, and, if so, what kinds of things should I be looking for? I am about halfway done with locking down the code, and haven't run into the same problems with the rewritten code. The server has frozen several times and required me to restart Cold Fusion server, but this could be attributed to the old code. While I am confident I am going to end up with a superior product in the end, I don't want to end up with egg on my face when the new version goes live because I got fixated on locks ... Any ideas would be appreciated. Thanks, M ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
