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
