Hi Andrew, Is it possible that Zope is crashing during the test? Might you try pointing the session data manager at a different transient object container (one not in the temp folder)? On Thu, 2003-01-23 at 22:48, Andrew Athan wrote:
Stranger and stranger. When the objects disappear, there is no slew of calls to the deleteScript ... it is looking like the session data manager just goes "poof"
A.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Andrew Athan Sent: Thursday, January 23, 2003 10:32 PM To: zope@zope.org Subject: RE: [Zope] Strange session behavior
Further information:
By printing request['_ZopeId'] I am able to see that the session ID is being maintained even after the session data disappears (thus, cookies are working fine). The problem is probably NOT in the browser ID manager.
By monitoring the transient object folder after setting all timeouts to 0 and using "ab -n 1000 http://localhost:8080/debug_test" to hit my little debug ZPT I see that the number of objects in the transient folder is periodically reset to 0 through no obvious action of my own.
Any clues or known bugs here?
Andrew Athan
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org] On Behalf Of Andrew Athan Sent: Thursday, January 23, 2003 9:49 PM To: zope@zope.org Subject: [Zope] Strange session behavior
Hi, I'm using Zope 2.6.1b1 (but the same behavior is exhibited by 2.6.0) and IE6 on XP. Before I spend a long time debugging this I thought I'd ask the list:
Either IE's cookie handling (doubt it, since I tried this with highly permissive privacy settinngs) or Zope's browser id manager, or Zope's session manager or Zope's transient objects folder is misbehaving.
Symptom: Session data is periodically and intermittently lost within a period of time much much shorter than the transient object timeout.
To test this I use a single IE window reloading the very same "test.html" ZPT that simply checks for the existance of the key 'foo' in REQUEST.SESSION and reports the result (and sets it to 1 always).
Preliminary evidence is that the problem is exacerbated by concurrent request handling. I test this using a windows client that utilizes the WinHTTP COM+ object to generate requests running on a separate machine (no chance of IE stepping on itself).
Of possible relevance is that external python methods are invoked to fulfill the WinHTTP generated requests.
Any initial hints on where to look?
Thanks, Andrew Athan