request finishes to recreate all the application-scope CFCs, because the
conditional is _outside_ the CFLOCK tag. In other words, request 1 will
come in, do the conditional, do the lock, do the initialization. Request 2
will come in, do the conditional, wait for the lock, get it, do the
initialization. Repeat for as many requests as come in before the first one
finishes.
If you move the conditional inside the CFLOCK tag, you'll solve that
problem. However, then you'll force every request to get that lock, which
is bad. To solve both problems, use a dual-lock, dual-conditional setup.
Here's how we do it:
<cflock scope="application" type="readonly" timeout="10">
<cfset reload_app_vars = NOT structKeyExists(application,
"app_vars_loaded") />
</cflock>
<cfif reload_app_vars>
<cflock scope="application" type="exclusive" timeout="60">
<cfif NOT structKeyExists(application, "app_vars_loaded")>
<!--- all kinds of initialization crap that I cut out --->
<!--- record that we successfully loaded all the variables --->
<cfset application.app_vars_loaded = true />
</cfif>
</cflock>
</cfif>
The first CFLOCK is read-only, so it won't generate any contention on
requests after the first, and sets a local variable about whether
initialization is needed. The first conditional skips initialization if
it's not needed. The second CFLOCK single threads access to the
initialization code. The second conditional checks to see if initialization
is still needed, now that this request is the ONLY request that could
possibly influence the outcome of that decision. That's the part you're
missing, which is allowing multiple requests to initialize the application,
thereby slowing it down.
I'm also using a dedicated variable for indicating whether the application
is loaded or not, rather than one of the actual application variables. I'd
recommend that, just for clarity's sake.
A side benefit of this, is that if you never write to any of the application
variables that you set in the initialization block, you never have to lock
any of the reads anywhere in the application. Keep in mind that instance
variables of application-scoped CFCs are actually application-scope
variables, so they count. However, if access to the instance variables is
synchronized inside the CFC using instance-specific named locks (a good
idea), then you needn't worry about them
Cheers,
barneyb
> -----Original Message-----
> From: Brook Davies [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 29, 2004 1:49 PM
> To: CF-Talk
> Subject: RE: Debugging CFMX
>
> Thanks for the feedback Barneyb, I appreciate it. I'm having massive
> trouble getting this app to start-up under load. I have
> already de-selected
> the save class files option because there were LOTS of class
> files, and I
> think this helped a bit.
>
> There is definitely something fishy going on, but I am not
> sure where it is
> exactly. My application contains two parts, they share an
> application.cfm
> file, but within that application.cfm file there are two different
> cfapplication tags. The main application is all pages other
> than a single
> cfm page that is used to handle 'external' requests. So, in
> pseudo code,
> the application.cfm does this:
>
>
> <cfif cgi.PATH_INFO is "/external_requesthandler.cfm">
>
> <!--- external request application framework --->
> <cfapplication name="logiformsV2_external">
>
> <!--- do initialization here --->
>
> <cfelse>
>
> <!--- site & member area application --->
> <cfapplication name="logiformsV2" setclientcookies="yes"
> clientmanagement="yes" clientstorage="logiforms_clientvars">
>
> <!--- do initialization here --->
>
> </cfif>
>
> The reason I am pointing this out, is because one of the
> applications, the
> site logiformsV2, starts up much more smoothly than the
> external request
> handling site (which essentially handles form submissions)
> which can hang
> forever...
>
> If we focus on the 'problem' app, the initialization code in the
> application.cfm looks like this:
>
> <cfif not isdefined("application.ComponentInstance.lfInsertData") or
> (attributes.refreshnow)>
> <!--- if the components are not defined set this var to true --->
> <cflock type="EXCLUSIVE" scope="APPLICATION" timeout="60">
> <!--- this flag will ensure that components are
> created by this
> thread only --->
> <cfif not
> isdefined("application.ComponentInstance.lfInsertData")>
> <cflog file="startupLog" date="yes" text="Running
> Instantiation of external application components">
> <cfobject component =
> "lfcomponents.triggers.triggerAction" name =
> "application.ComponentInstance.triggerAction">
> <cfobject component =
> "lfcomponents.lfinsert_record" name
> = "application.ComponentInstance.lfInsertData">
> <cfobject component =
> "lfcomponents.lfincrement" name =
> "application.ComponentInstance.lfincrement">
> <cfobject component =
> "lfcomponents.lfcreatetable" name =
> "application.ComponentInstance.lfcreatetable">
> <cfobject component =
> "lfcomponents.lfdescript_string"
> name = "application.ComponentInstance.lfdescript_string">
> </cfif>
> </cflock>
> </cfif>
>
> Now, my startup log file only contains one line, which I
> guess indicates
> that this is working, and only being run by one thread.
>
> "Information","jrpp-18","06/29/04","12:20:49","LOGIFORMSV2_EXT
> ERNAL","Running
> Instantiation of external application components"
>
> But, for whatever reason, this app still has a hell of a time
> starting up.
> Sometimes the thread count will grow and grow and the
> processor will sit at 0!
>
> If I set the server's timeout to 20 seconds, that seems to
> help get the
> server started, about 10 threads will timeout, but then the
> server will get
> started. The threads that timeout are usually,
> cfquery,cfmail and cfloops
> in various places. The really strange thing is that, on the
> first run, if
> I look at the template execution stack and look for what took
> so bloody
> long, there is usually always one template that took a really
> long time.
> But this changes from time to time, and if I manually exclude
> that template
> from the startup sequence, another template (unrelated)
> becomes the long
> running template....
>
> Anyways, I got some serious problems, and If I don't fix em,
> I ain't going
> to Mexico this summer! lol
>
> I wish there was a way to get a more detailed look at what
> the server is
> doing internally while it was starting up, like what
> templates/code it is
> hanging on etc...
>
> Brook Davies
> logiforms.com
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
