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
