yeah...another good point :P id suggest an include file but that doesnt really save you any work other than the hope that having a common include file across all your files would make it easier to add new features globaly - like maybe adding a navigation bar to all pages or something like that - but thts pretty far fetched i guess :P
----- Original Message ----- From: "Bill Conlon" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, January 06, 2005 12:26 PM Subject: Re: Witango-Talk: Preloading the Witango Cache > Alan, > > thx for the suggestion. Actually, that's an ideal use of a TCF (catch > 22 again). But yes, probably the only certain approach is to check > each time a taf is executed. > > But that's an unwarranted (in my opinion) burden on both developers and > users. > > On Thursday, January 6, 2005, at 12:25 PM, Alan Wolfe wrote: > > > 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 > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
