Hi Ted, That could explain a few things. A VariableTimeout of zero means to "never" expire.
Yes, I could easily imagine your Server slowing down to a crawl because new variables are constantly being added to memory, but never purged. The [Expired] entries might be coming from some feature of the Server that is forced to clean house under extreme conditions possibly? The default is 30 (minutes), and the behavior is based on the last time the "visitor" with the associated UserReference key requests a TAF or TML file. If they don't access a TAF or TML for more than 30 minutes, the system purges whatever variables are associate with that key. Hope this helps. Cheers..... Scott Cadillac, 403-281-6090 ~ [EMAIL PROTECTED] ------------ XML-Extranet ~ http://xmlx.ca ~ http://forums.xmlx.ca Well-formed Programming in C# .NET, Witango, MSIE and XML ------------ Witango ~ http://witango.org EasyXSLT ~ http://easyxslt.ca IIS Watcher ~ http://iiswatcher.ca ------------ -----Original Message----- From: Ted Wolfley <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Date: Thu, 4 Mar 2004 14:27:40 -0500 Subject: RE: Witango-Talk: witango log > Our VARIABLETIMEOUT= is set to zero and we are not resetting it in > code. I > can't remember if we changed it or/and if we did, why we changed it. > Does > the variable timeout from the last time it is accessed? What is the > preferred number for it? > > Thanks > > Ted > > -----Original Message----- > From: Scott Cadillac [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 04, 2004 2:12 PM > To: [EMAIL PROTECTED] > Subject: RE: Witango-Talk: witango log > > > Hi Ted, > > What is your VARIABLETIMEOUT= set to? > > An [Expired] entry in your log file should show some activity for that > key "x" mintures earlier (where "x" is equal to VARIABLETIMEOUT=). > > Or are you doing <@ASSIGN User$variableTimout VALUE="x"> somewhere in > your code? This can override the VARIABLETIMEOUT= in the server.ini > file. > > Hope this helps. Cheers... > > > -----Original Message----- > From: Ted Wolfley <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Date: Thu, 4 Mar 2004 13:59:59 -0500 > Subject: RE: Witango-Talk: witango log > > > I did a random search on a few userreferences that are in the expired > > section and that is the only place that they appear. And we have had > > instances of user variables being lost but they are so random it is > > hard to track down the cause. > > > > Ted > > > > -----Original Message----- > > From: Scott Cadillac [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 04, 2004 1:39 PM > > To: [EMAIL PROTECTED] > > Subject: Re: Witango-Talk: witango log > > > > > > Hi Ted, > > > > I was just having a very similar discussion off-list with someone > > else. > > > > Where you crawled by a search engine(s) this morning? > > > > These kinds of entries are normal, but an "excessive" amount can > point > > to one or two things: > > > > ----------- > > ~~ Search Engines normally do not (or care about) the ability to > store > > cookies and the UserReference key used for managing User Scope > > variables > > is a "session-cookie". Witango typically issues these keys > > automatically. > > > > So "each page" crawl from an Engine is just like a new visitor to > your > > site. Each crawl is typically issued a new UserReference key. > > > > This is normal behavior, and there is nothing wrong with this (other > > platforms like PHP and ASP also use session-cookies this way) - but > > it's > > also a good reason to not assign too many User Scope variables > > unnecessarily. > > > > As a rule, I only assign a User Scope variable if I have a "very" > good > > reason to. > > > > Note: the same above behavior can also come from robot scripts > > attacking a website. > > > > ----------- > > ~~ The other reason could be that something in your code is > preventing > > the Witango server from issuing the keys properly in a managed > fashion, > > and the fall back behavior of the Server is to keep issuing new ones > > (if > > the previous ones are going missing). > > > > This can happen if you have any custom local$httpHeader variable > > assignments that don't also include <@userreferencecookie>, or use it > > properly. > > > > --- > > The [Expired], in your logs, comes from when these previously used > > session-cookies go unused for whatever your default expiry time is > > (default is 30 minutes). > > > > Open your log file in a text editor, select one of the expired key > > values lower down in the file - then search "up" to see how many > times > > that key > > was used. This can help point to your problem (if any). > > > > --- > > Do your Users sometime loose their sessions (User variables)? > > > > Let us know, otherwise I hope this helps. Cheers... > > > > Scott Cadillac, > > 403-281-6090 ~ [EMAIL PROTECTED] > > ------------ > > XML-Extranet ~ http://xmlx.ca ~ http://forums.xmlx.ca Well-formed > > Programming in C# .NET, Witango, MSIE and XML > > ------------ > > Witango ~ http://witango.org > > EasyXSLT ~ http://easyxslt.ca > > IIS Watcher ~ http://iiswatcher.ca > > ------------ > > > > > > -----Original Message----- > > From: Ted Wolfley <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Date: Thu, 4 Mar 2004 13:17:05 -0500 > > Subject: Witango-Talk: witango log > > > > > Hi, > > > > > > I just restarted the our witango 5.0 service on a windows 2000 > > > server because the webpages were slow in coming up. When I looked > > > into the witango server log, there were 4801 entries of "[Expired] > > > Variables for key". each entry had a different key. The service > was > > > restarted 12:00am this morning. > > > Are these entries normal and can a build up of userreferences slow > > down > > > the > > > server? > > > > > > > > > Ted Wolfley > > > Database/Internet Programmer > > > The Ogden Group of Rochester > > > phone: (585) 321 1060 x23 > > > fax: (585) 321 0043 > > > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > > > > > > www.ogdengroup.com <http://www.ogdengroup.com/> > > > > > > > > > > > > > > > ______________________________________________________________________ > > > _ > > > _ > > > 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
