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