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
