good point. no idea on that one
something else you might try if you need to do this is at the top of your files which need a tcf invoked for that application scope, at the very top of the taf, just have an if statement to check if the tcf already exists in application scope. If it doesnt, then create it. ----- Original Message ----- From: "Bill Conlon" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, January 06, 2005 12:11 PM Subject: Re: Witango-Talk: Preloading the Witango Cache > I need to instantiate an object in application scope when witango > starts. How do I use a TCF to do that? > > On Thursday, January 6, 2005, at 12:15 PM, Alan Wolfe wrote: > > > have you thought about using TCF functions instead of having <@url> > > call > > another file? (: > > > > ----- Original Message ----- > > From: "Bill Conlon" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Thursday, January 06, 2005 12:02 PM > > Subject: Re: Witango-Talk: Preloading the Witango Cache > > > > > >> John, > >> > >> I originally built a startup.taf that would query a db for the various > >> actions to be done (which domains get initialized), then use a FOR > >> loop > >> to issue a sequence @URL to the appropriate tafs, with error detection > >> by putting the results into a DOM variable and looking for the status. > >> > >> Alas, the problem is the witangod doesn't accept user requests until > >> startup.taf completes, and the @URLs issued by startup.taf are > >> considered user requests. Catch 22. > >> > >> That's why I basically abandoned using witango's startup_url function. > >> It seems that it is only useful for setting up the non-witango > >> environment. I think I tried your approach -- have my startup_url > >> execute a taf that invokes a perl script, which then waits a few > >> seconds before issuing initialization requests to witango. But we > >> really need to fork that request, so witango can finish processing the > >> startup_url, and I was never successful in figuring out how to make > >> that happen. But maybe having the script trigger at would be the way. > >> > >> But you're right, no-one wants to wait a minute (potentially 1 minute > >> 59.999 seconds). > >> > >> On Thursday, January 6, 2005, at 11:42 AM, John McGowan wrote: > >> > >>> Bill, > >>> > >>> Instead of the changes you made to the init script, have you thought > >>> about doing the following... > >>> > >>> have your startup.taf file as normal. > >>> > >>> in startup.taf call an external action to shellscript1.sh > >>> > >>> in shellscript1.sh, have a call to "at" to call shellscript2.sh in 1 > >>> minute > >>> > >>> 1 minute later, shellscript2.sh should execute, and that could > >>> contain > >>> all the initialization code that you needed with calls to the various > >>> domains *init.taf* scripts. > >>> > >>> Potential Problem > >>> I don't think you can specify a smaller time period than 1 minute > >>> with > >>> *at *so you might not want to wait a whole minute before doing the > >>> init work. > >>> > >>> > >>> This will work when the process dies and is restarted, because it is > >>> still triggered by the startup url... > >>> > >>> > >>> You know what I would like... The ability to specify more than 1 URL > >>> (perhaps separated by semi colons) in the startup URL string. that > >>> way multiple startup url's could be executed. > >>> > >>> /John > >>> > >>> > >>> Bill Conlon wrote: > >>> > >>>> This really cries out for startup_url to be fixed, so we can > >>>> actually > >>>> have control of the witango environment when it restarts. > >>>> > >>>> I have a quasi-fix involving the startup script: sleep a fixed time > >>>> before issuing a startup.taf to initialize application and domain > >>>> variables/objects > >>>> > >>>> This works okay as long as the witangod only restarts under my (or > >>>> my > >>>> proxy, such as cron, at, etc) control. But if witango restarts > >>>> itself, then things won't get initialized since startup.taf will > >>>> get > >>>> rejected by witango, saying witango is not accepting requests. > >>>> > >>>> It has been my good fortune that on my production system (Redhat 9), > >>>> witango has NEVER restarted itself. But just this week, my > >>>> development system did (a taf I was working on apparently caused > >>>> it). So this has gotten me to worry about this issue again -- if > >>>> witango restarts, how can I be sure that the environment is > >>>> correct? > >>>> > >>>> A more general work-around would be a MON service for witango. > >>>> Rather than examining the process list, I think I might rather look > >>>> at the witangoevents.log. I envision a daemon-like process waiting > >>>> for input that's tee'd from the log. When we get the message > >>>> "Started accepting user requests" then we issue our startup.taf. > >>>> > >>>> But this kludge REALLY should not be needed! > >>>> > >>>>> After a witangod restart or purge of the witango cache, requests > >>>>> are > >>>>> coming in from the outside to files on the witango driven sites. > >>>>> Every hit to the site is through a content management system that > >>>>> consists of 1 TAF and a couple of large TCF files. Without > >>>>> caching, > >>>>> these sites wouldn't run well at all, because witango takes too > >>>>> long to load the xml, parse it and execute it. However, once the > >>>>> first hit comes in, and the taf and tcf files are cached, > >>>>> everything runs lickety split. But, since there are multiple hits > >>>>> coming, in, there is the potential that there are several threads > >>>>> all trying to populate the cache with a large tcf. Then it takes > >>>>> a > >>>>> lot longer for the site's response time to be acceptable... But if > >>>>> i could force the server to not be multi threaded I wouldn't have > >>>>> threads competing for IO and CPU time. > >>>>> > >>>>> I thought about setting a startup url in witango.ini to be a > >>>>> startup.taf and have startup.taf execute some @url calls to > >>>>> prepopulate the cache on multiple sites running on this box. > >>>>> problem is though that those @url calls all fail with the "Server > >>>>> is starting up" message, (Same exact problem that Bill Conlon had > >>>>> a while back when trying to initalize domain variables.) > >>>>> > >>>>> So now I'm thinking about this... perhaps i can set witango.ini's > >>>>> thread pool size to 1 on server startup, and change it on the fly > >>>>> to > >>>>> a higher value? Is that possible, will the server allow me to > >>>>> increase the threads after the server has been running for a > >>>>> minute > >>>>> or so? Then the only tricky thing to do is to have the url called > >>>>> that increases the threadpool size at the right time after the > >>>>> server restarts. perhaps this is a job for the at command. > >>>>> > >>>>> Before I went and tried to mess with the threadpool size while the > >>>>> server is running i thought i'd check here first to see if it's > >>>>> even > >>>>> possible. > >>>>> > >>>>> /John > >>>>> ___________________________________________________________________ > >>>>> __ > >>>>> __ _ > >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >>>>> > >>>> > >>>> ____________________________________________________________________ > >>>> __ > >>>> __ > >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >>>> > >>> _____________________________________________________________________ > >>> __ > >>> _ > >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >>> > >> > >> ______________________________________________________________________ > >> __ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > _______________________________________________________________________ > > _ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
