When set to false, a new
server is started immediately, even before the old one is stopped. This setting
ensures high server availability, but variables from the old server instance are
not available in the new one. The default value is true.
I'm not 100% but I think this will bypass the dump
file and come back with empty domain variables (at least that is what my tests
have concluded).
In regards to your load splitting scenario, it
doesn't look good. I searched the archives and found the
following:
http://www.witango.com/readmail.taf?_function=detail&id=3210
http://www.witango.com/readmail.taf?_function=detail&id=1548
http://www.witango.com/readmail.taf?_function=detail&id=1547
This pretty much rules out load-splitting for anyone
using Domain Vars to control content (if you wanted to search the database to
get the values each time you wouldn't have used Domain Vars to begin
with). Maybe this has changed from Tango2000 to Witango 5 but I doubt
it. It would be great if someone from With Enterprises could confirm
this!
Good Luck,
Dominick
----- Original Message -----
Sent: Friday, June 20, 2003 12:26
PM
Subject: RE: Witango-Talk: Startup URL
and Domain Variables
Upon further investigation, we were able to verify that the
STARTUPURL
runs consistently but the taf called does
not process the @URL tag. It
processes
everything else but that tag. Oddly, we can still run the taf
by hand and get the @URL to process correctly. Any
thoughts?
One of the reasons we require the domain vars to be
initialized during
startup is that we have
historically found that the dump file gets
"out-of-date" when Witango does not shut down properly (since it does
not
get a chance to write the most recent variable
values). Thus when Witango
restarts after a crash the
"wrong" dump file is read. In addition, even
though the VariableTIMEOUT is set to 0 in the domain scope,
persistence
across restarts does not always occur even
when the server is shut down
properly.
We are hopeful that there we be few instance where Witango
shuts down
improperly with Ver5, but it is crucial for
us to have up-to-date domain
variable values at all
times the server is running. At this point, our
workaround is to delete the dump file at startup and shutdown and
force
the domain variable restoration the first time a
taf is called. It would
almost be better if we
could turn off the dump file execution since
inconsistent file writing is worse (for us) than no file
writing.
Most importantly, in a load splitting scenario where multiple
instances of
Witango server are installed on one (or
more) machine, is that we have the
capability of
maintaining the same set of domain vars across all Witango servers.
For example, if the admin of one of our sites was on
instance 1 and updated
a domain var, that value would
need to be maintained on instance 2,3 etc.
It would
seem to me that this scenario would also exist for custom scoped
variables. However, we have not seen anything in
the docs that explicitly
discuss this area and have
found our initial testing to be somewhat frustrating.
Any thoughts here are also greatly appreciated.
My apologies for rambling on...
Thanks
John
-----Original Message-----
From: Scott
Cadillac [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 19, 2003 7:12 PM
To:
[EMAIL PROTECTED]
Subject: RE: Witango-Talk:
Startup URL and Domain Variables
Hi John,
I'm going to guess that the problem might be more to do with
STARTUPURL then
<@URL>.
Maybe the Server cannot find the address of the TAF specified
in STARTUPURL?
The "HOSTS" file is handy for these
kinds of things.
Do you know if STARTUPURL is successfully calling the TAF at
all?
Because the execution of the TAF in this case is not easy to
see, try
putting something like a File/Write Action in
the TAF that records something
in a text/log file -
just to verify the TAF is executed.
And no, I don't think it's possible to initialize Domain
Variables from
outside the Domain - unless you use
<@URL> of course.
Custom Scope works almost exactly like Domain Scope, except
the Variables
are visible across all Domains present
on the Server. Just watch your
naming, to make sure
things don't get stepped on.
Sometimes having the Variables visible across Domains is a
good thing
because then sites with more than one
address on the same Server (e.g.,
www.mydomain.com and
mydomain.com) can share one Custom Scope Variable as
opposed to two Domain Scope Variables that are supposedly the same
value.
Hope this helps. Cheers....
Scott Cadillac,
Witango.org - http://witango.org
403-281-6090 - [EMAIL PROTECTED]
--
Information for the Witango Developer Community
---------------------
XML-Extranet - http://xml-extra.net
403-281-6090 - [EMAIL PROTECTED]
--
Well-formed Development (for hire)
---------------------
-----Original Message-----
From: John
Hotaling [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 19, 2003 4:34 PM
To: [EMAIL PROTECTED]
Subject:
Witango-Talk: Startup URL and Domain Variables
I have the need to reinitialize domain variables for
several domains from values stored in a db. It
is
critical that these values are current any time
Witango starts
or restarts. In the past,
we have used the startup URL
to call a taf (ironically
we can run this taf by hand in a
browser fine) that
told us which domains required initialization.
This
taf in turn uses an @URL tag to "restore" domain vars for
each respective domain. However, we have not had success
using this logic with V5 of Witango and do not know
why.
We have tried the new parameters for the @URL tag
without
any luck. Is there any reason why our
startup URL will not
run with the @URL tag used in
it? It is not reporting any errors
in the log
files during startup.
Also, is there a way to set
domain vars for a specific domain from
within a
different domain? Although it does not intuitively
make sense to me that you could, I thought I would still pose
the question.
Thanks in
advance for any assistance.
Witango Application Server
(Multiple Edition) 5.0.1.054 Chimera (Win32)
Windows2000/5.0; INTEL
John
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
