[Zope] Strange session behavior
Andrew Athan
zope-response@memeplex.com
Thu, 23 Jan 2003 22:31:34 -0500
This is a multi-part message in MIME format.
------=_NextPart_000_0035_01C2C32F.32E2AA70
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
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
------=_NextPart_000_0035_01C2C32F.32E2AA70
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D861062903-24012003>Further information:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D861062903-24012003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D861062903-24012003>By=20
printing request['_ZopeId'] I am able to see that the session ID is =
being=20
maintained even after the session data disappears (thus, cookies are =
working=20
fine). The problem is probably NOT in the browser ID=20
manager.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D861062903-24012003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D861062903-24012003>By=20
monitoring the transient object folder after setting all timeouts to 0 =
and using=20
"ab -n 1000 http://localhost:8080/debug_test" to hit my little debug ZPT =
I see=20
that the number of objects in the transient folder is periodically reset =
to 0=20
through no obvious action of my own.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D861062903-24012003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D861062903-24012003>Any=20
clues or known bugs here?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D861062903-24012003></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D861062903-24012003>Andrew=20
Athan</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
zope-admin@zope.org [mailto:zope-admin@zope.org] <B>On Behalf Of =
</B>Andrew=20
Athan<BR><B>Sent:</B> Thursday, January 23, 2003 9:49 PM<BR><B>To:</B> =
zope@zope.org<BR><B>Subject:</B> [Zope] Strange session=20
behavior<BR><BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial size=3D2>Hi, =
I'm using Zope=20
2.6.1b1 (but the same behavior is exhibited by 2.6.0) and IE6 on =
XP. =20
Before I spend a long time debugging this I thought I'd ask the=20
list:</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial =
size=3D2>Either IE's cookie=20
handling (doubt it, since I tried this with highly permissive privacy=20
settinngs) or Zope's browser id manager, or Zope's session manager or =
Zope's=20
transient objects folder is misbehaving.</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial =
size=3D2>Symptom: =20
Session data is periodically and intermittently lost within a period =
of time=20
much much shorter than the transient object =
timeout.</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial size=3D2>To =
test this I use=20
a single IE window reloading the very same "test.html" ZPT that simply =
checks=20
for the existance of the key 'foo' in REQUEST.SESSION and reports the =
result=20
(and sets it to 1 always).</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial =
size=3D2>Preliminary=20
evidence is that the problem is exacerbated by concurrent request=20
handling. I test this using a windows client that utilizes the =
WinHTTP=20
COM+ object to generate requests running on a separate machine (no =
chance of=20
IE stepping on itself).</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial size=3D2>Of =
possible=20
relevance is that external python methods are invoked to fulfill the =
WinHTTP=20
generated requests.</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial size=3D2>Any =
initial hints=20
on where to look?</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial=20
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D611154102-24012003><FONT face=3DArial =
size=3D2>Andrew=20
Athan</FONT></SPAN></DIV>
<DIV><SPAN=20
class=3D611154102-24012003></SPAN> </DIV></BLOCKQUOTE></BODY></HTML>=
------=_NextPart_000_0035_01C2C32F.32E2AA70--