Accessing session variables fails occasionally--perhaps once every 10000 references or so! (See collector issue #848 where I just added a comment.) Presumably this is a read conflict in temporary_folder. The access to the variable uses a python script-- request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise oopsSession() is a debug routine which reports that it cannot find REQUEST. This is Zope 2.6.2b3 and Python 2.1.3. This version of Zope is patched to NOT use the (flawed) LowConflictConnection for temporary storage. This is a critical bug for us and is becoming more so as our usage grows. It's a showstopper for our users as we are entirely session based! It's fairly likely that some internal data structure gets corrupted. We tend to fetch session variables in clusters, and when one fails all subsequent ones fail. Sad to say, the failure kills the user's session and releases a burst of emotional energy )-: Any suggestions for a fix or workaround? This particular bug has been seen in 2.7.4 so upgrading is not going to fix things.
Yes, this bug is in every version of Zope including the most recent. Yes, it's bad. Yes, it should be fixed. I wish I had a fix for it. - C On Thu, 2004-02-19 at 12:35, Dennis Allison wrote:
Accessing session variables fails occasionally--perhaps once every 10000 references or so! (See collector issue #848 where I just added a comment.)
Presumably this is a read conflict in temporary_folder. The access to the variable uses a python script--
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
oopsSession() is a debug routine which reports that it cannot find REQUEST.
This is Zope 2.6.2b3 and Python 2.1.3. This version of Zope is patched to NOT use the (flawed) LowConflictConnection for temporary storage.
This is a critical bug for us and is becoming more so as our usage grows. It's a showstopper for our users as we are entirely session based!
It's fairly likely that some internal data structure gets corrupted. We tend to fetch session variables in clusters, and when one fails all subsequent ones fail. Sad to say, the failure kills the user's session and releases a burst of emotional energy )-:
Any suggestions for a fix or workaround? This particular bug has been seen in 2.7.4 so upgrading is not going to fix things.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d On Thu, 19 Feb 2004, Chris McDonough wrote:
Yes, this bug is in every version of Zope including the most recent. Yes, it's bad. Yes, it should be fixed. I wish I had a fix for it.
- C
On Thu, 2004-02-19 at 12:35, Dennis Allison wrote:
Accessing session variables fails occasionally--perhaps once every 10000 references or so! (See collector issue #848 where I just added a comment.)
Presumably this is a read conflict in temporary_folder. The access to the variable uses a python script--
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
oopsSession() is a debug routine which reports that it cannot find REQUEST.
This is Zope 2.6.2b3 and Python 2.1.3. This version of Zope is patched to NOT use the (flawed) LowConflictConnection for temporary storage.
This is a critical bug for us and is becoming more so as our usage grows. It's a showstopper for our users as we are entirely session based!
It's fairly likely that some internal data structure gets corrupted. We tend to fetch session variables in clusters, and when one fails all subsequent ones fail. Sad to say, the failure kills the user's session and releases a burst of emotional energy )-:
Any suggestions for a fix or workaround? This particular bug has been seen in 2.7.4 so upgrading is not going to fix things.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
FWIW, I used HappySession a few years ago and it worked well for me. But then, it was never run on a busy server. Still, its very similar to Zope Session and if all else fails it may be worth a look. I am not sure if HappySession is still supported or if It will run on Zope 2.7. I run it on Zope 2.6x. Also, if anyone knows of problems w/it I would be interested to hear. David ----- Original Message ----- From: "Dennis Allison" <allison@sumeru.stanford.EDU> To: "Chris McDonough" <chrism@plope.com> Cc: <zope@zope.org> Sent: Thursday, February 19, 2004 1:30 PM Subject: Re: [Zope] SESSION Errors
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
On Thu, 19 Feb 2004, Chris McDonough wrote:
Yes, this bug is in every version of Zope including the most recent. Yes, it's bad. Yes, it should be fixed. I wish I had a fix for it.
- C
On Thu, 2004-02-19 at 12:35, Dennis Allison wrote:
Accessing session variables fails occasionally--perhaps once every 10000 references or so! (See collector issue #848 where I just added a comment.)
Presumably this is a read conflict in temporary_folder. The access to the variable uses a python script--
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
oopsSession() is a debug routine which reports that it cannot find REQUEST.
This is Zope 2.6.2b3 and Python 2.1.3. This version of Zope is patched to NOT use the (flawed) LowConflictConnection for temporary storage.
This is a critical bug for us and is becoming more so as our usage grows. It's a showstopper for our users as we are entirely session based!
It's fairly likely that some internal data structure gets corrupted. We tend to fetch session variables in clusters, and when one fails all subsequent ones fail. Sad to say, the failure kills the user's session and releases a burst of emotional energy )-:
Any suggestions for a fix or workaround? This particular bug has been seen in 2.7.4 so upgrading is not going to fix things.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
I'd like to stay with standard release stuff if I can. That sorta means fixing the current product. On Thu, 19 Feb 2004, David Hassalevris wrote:
FWIW, I used HappySession a few years ago and it worked well for me. But then, it was never run on a busy server. Still, its very similar to Zope Session and if all else fails it may be worth a look. I am not sure if HappySession is still supported or if It will run on Zope 2.7. I run it on Zope 2.6x. Also, if anyone knows of problems w/it I would be interested to hear. David
----- Original Message ----- From: "Dennis Allison" <allison@sumeru.stanford.EDU> To: "Chris McDonough" <chrism@plope.com> Cc: <zope@zope.org> Sent: Thursday, February 19, 2004 1:30 PM Subject: Re: [Zope] SESSION Errors
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
On Thu, 19 Feb 2004, Chris McDonough wrote:
Yes, this bug is in every version of Zope including the most recent. Yes, it's bad. Yes, it should be fixed. I wish I had a fix for it.
- C
On Thu, 2004-02-19 at 12:35, Dennis Allison wrote:
Accessing session variables fails occasionally--perhaps once every 10000 references or so! (See collector issue #848 where I just added a comment.)
Presumably this is a read conflict in temporary_folder. The access to the variable uses a python script--
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
oopsSession() is a debug routine which reports that it cannot find REQUEST.
This is Zope 2.6.2b3 and Python 2.1.3. This version of Zope is patched to NOT use the (flawed) LowConflictConnection for temporary storage.
This is a critical bug for us and is becoming more so as our usage grows. It's a showstopper for our users as we are entirely session based!
It's fairly likely that some internal data structure gets corrupted. We tend to fetch session variables in clusters, and when one fails all subsequent ones fail. Sad to say, the failure kills the user's session and releases a burst of emotional energy )-:
Any suggestions for a fix or workaround? This particular bug has been seen in 2.7.4 so upgrading is not going to fix things.
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
On Thu, 2004-02-19 at 16:30, Dennis Allison wrote:
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
Yes. And I haven't been successful. I suspect that it's something related to conflict errors. - C
C and D: As to conflict errors, does this mean READ conflicts, as in trying to read the session info? If that is the case, then might it not work to try reading twice before flipping to the error? Here's the code snippet from Dennis:
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
Why not make this more like (completely untested, and this is not my forte, but just thinking out loud): request=container.REQUEST try: session=request['SESSION'] return session[varname] except try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise 100:1 against this "try:try:except" structure being valid, but given that there is some analogous structure that would have this effect, I would think that if there is a 1 in 10,000 chance of failure reading the SESSION once, then there's a similar 1 in 10,000 chance of failure reading it a second time, and that makes it a 1 in 100,000,000 chance of failure by nesting... and the nested try: would only be activated maybe once 1 in 10,000 times, making it a non-issue as far as performance. Just my ha'penny, unencumbered by real knowledge of these deep innards of zope... =Paul At 05:36 PM 2/19/2004, Chris McDonough wrote:
On Thu, 2004-02-19 at 16:30, Dennis Allison wrote:
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
Yes. And I haven't been successful. I suspect that it's something related to conflict errors.
- C
Might work, but I doubt it. I think it's always best to attack this sort of stuff on first principles. The quantity of code is tiny (10s of lines) but it's hard to grok. On Thu, 19 Feb 2004, Paul Howell wrote:
C and D: As to conflict errors, does this mean READ conflicts, as in trying to read the session info?
If that is the case, then might it not work to try reading twice before flipping to the error?
Here's the code snippet from Dennis:
request=container.REQUEST try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
Why not make this more like (completely untested, and this is not my forte, but just thinking out loud):
request=container.REQUEST try: session=request['SESSION'] return session[varname] except try: session=request['SESSION'] return session[varname] except KeyError: container.oopsSession( varname ) raise
100:1 against this "try:try:except" structure being valid, but given that there is some analogous structure that would have this effect, I would think that if there is a 1 in 10,000 chance of failure reading the SESSION once, then there's a similar 1 in 10,000 chance of failure reading it a second time, and that makes it a 1 in 100,000,000 chance of failure by nesting... and the nested try: would only be activated maybe once 1 in 10,000 times, making it a non-issue as far as performance.
Just my ha'penny, unencumbered by real knowledge of these deep innards of zope... =Paul
At 05:36 PM 2/19/2004, Chris McDonough wrote:
On Thu, 2004-02-19 at 16:30, Dennis Allison wrote:
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
Yes. And I haven't been successful. I suspect that it's something related to conflict errors.
- C
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Yup.... I'm looking into it, adding some trace code, etc. The fact that it is actually rare make it hard to trace. On Thu, 19 Feb 2004, Chris McDonough wrote:
On Thu, 2004-02-19 at 16:30, Dennis Allison wrote:
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
Yes. And I haven't been successful. I suspect that it's something related to conflict errors.
- C
Chris McDonough wrote:
On Thu, 2004-02-19 at 16:30, Dennis Allison wrote:
Chris-- I need to squash this bug. Any thoughts as to were to begin. Have you tried to locate the error? -d
Yes. And I haven't been successful. I suspect that it's something related to conflict errors.
- C
If it's any help, I recently found myself in a situation where sessions caused trouble relating to conflict errors. What was happening, I think, was an intervening proxy server. What I needed was: user A on machine 1 user B on machine 2 user C on machine 3 username was from basic authentication. machine id was determined automatically by the sessioning mechanism. But machines 1,2,3 were sharing a proxy server. Let's call the proxy server machine 7. What I got was: user A on machine 7 user B on machine 7 user C on machine 7 The result was unresolvable conflict errors, and I think it was only if two or more users' responses in a field differed within a very short time. I had to abandon sessions and put the user-specific data in the relational database, keyed by username. -- Jim Washington
Hello All, A problem appeared recently after some system reconfiguration (now Debian 3.0, Zope 2.6.2, Postgresql 7.2.1 at Celeron-366/512 Mb RAM, Apache is not used)- opening any link in a Zope application (mostly in OIO, www.txoutcome.org) unpredictable causes "Server not found..." error and if through Squid - "Zero sized reply" or "Permission denied". Pressing "Refresh" 4-10-12 times still opens the link. Any hint how to fix this? -- Best regards, Alexander N. Chelnokov Ural Scientific Research Institute of Traumatology and Orthopaedics 7, Bankovsky str. Ekaterinburg 620014 Russia
Hello All, Saturday, February 28, 2004, 10:42:22 AM, you wrote: AC> Hello All, AC> Apache is not used)- opening any link in a Zope application (mostly in AC> OIO, www.txoutcome.org) unpredictable causes "Server not found..." Sorry, IE reports "Cannot find server or DNS error". AC> error and if through Squid - "Zero sized reply" or "Permission AC> denied". Pressing "Refresh" 4-10-12 times still opens the link. Any AC> hint how to fix this? -- Best regards, Alexander N. Chelnokov Ural Scientific Research Institute of Traumatology and Orthopaedics 7, Bankovsky str. Ekaterinburg 620014 Russia
Alexander Chelnokov wrote at 2004-2-28 11:09 +0500:
Saturday, February 28, 2004, 10:42:22 AM, you wrote:
AC> Hello All,
AC> Apache is not used)- opening any link in a Zope application (mostly in AC> OIO, www.txoutcome.org) unpredictable causes "Server not found..."
Sorry, IE reports "Cannot find server or DNS error".
This might be a DNS problem. Try to use the IP address directly (the easiest way is an entry in the "hosts" file on the client computer). If this works reliably, the problem is in the DNS service. If it does not, try to directly send requests to Zope (no intervening Squid and Apache). -- Dieter
Hello Dieter, Sunday, February 29, 2004, 3:04:28 AM, you wrote:
IE reports "Cannot find server or DNS error". DM> This might be a DNS problem.
Google search resulted with http://mail.zope.org/pipermail/zope/2001-November/103402.html Looks like the problem was caused by old version of psycopg DA... After its upgrade all looks OK. -- Best regards, Alexander N. Chelnokov Ural Scientific Research Institute of Traumatology and Orthopaedics 7, Bankovsky str. Ekaterinburg 620014 Russia
participants (7)
-
Alexander Chelnokov -
Chris McDonough -
David Hassalevris -
Dennis Allison -
Dieter Maurer -
Jim Washington -
Paul Howell