Michael Dunstan wrote:
On 18/05/2004, at 10:03 PM, Andrea Patuzzo wrote:
Hi, dear developers:
We are now randomly getting this kind of error:
[...]
File
/usr/local/Zope270CVS/lib/python/Products/Transience/Transience.py,
line 341, in __setitem__
current_bucket = self._data[current_ts]
On Mon, 2004-05-17 at 23:08, Chris McDonough wrote:
There indeed is a minor off-by-one error: it manifests itself as
sessions timing out at most 20 seconds early.
But there is also a deeper issue which involves the fact that a session
data object is not properly removed from an older bucket
Hi, dear developers:
We are now randomly getting this kind of error:
2004-05-18T11:30:41 ERROR(200) SiteError
http://XXX/prefs_error_log_form
Traceback (most recent call last):
File /usr/local/Zope270CVS/lib/python/ZPublisher/Publish.py, line 100,
in publish
request,
Good morning.
I just got in and checked on my customer's system. In the past 22 1/2
hours they've had 15000 page hits and last night at about 9:30, ONE
person got a KeyError. Actually, this same person got twenty KeyErrors
over a period of about 45 seconds. I'm downloading their log files
Andrea Patuzzo wrote:
We are now randomly getting this kind of error:
Note: once the error happens, zope has to be restarted to function again.
Before applying patches we were getting get errors (instead of
__setitem__) and we just had to close browser to get back to work.
That's right. Under
Well, after much log reading, I have found that the KeyError we got last
night was OUR fault.
I will fix the problem with our app, then I want to change back to
TemporaryStorage and watch the system some more. I'll keep you posted.
Here's the brief explanation of our problem (you can skip it
On 18/05/2004, at 10:03 PM, Andrea Patuzzo wrote:
Hi, dear developers:
We are now randomly getting this kind of error:
[...]
File
/usr/local/Zope270CVS/lib/python/Products/Transience/Transience.py,
line 341, in __setitem__
current_bucket = self._data[current_ts]
KeyError: 1084872640
:-(
I grabbed Transience.py and TemporaryStorage.py from the Zope-2_7-branch
of CVS this morning and dropped them onto one of our customer's systems.
About 20 minutes later I found the following in the error_log:
Traceback (most recent call last):
On Mon, 2004-05-17 at 12:09, Steve Jibson wrote:
:-(
I grabbed Transience.py and TemporaryStorage.py from the Zope-2_7-branch
of CVS this morning and dropped them onto one of our customer's systems.
About 20 minutes later I found the following in the error_log:
On Mon, 17 May 2004 19:00:16 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:
Chris McDonough wrote at 2004-5-15 13:04 -0400:
...
Dieter, do you think you can read this patch and give a thumbs up or
down on it?
The patch looks good.
On a different subject, the publisher probably shouldn't
Casey Duncan wrote:
On Mon, 17 May 2004 19:00:16 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:
Chris McDonough wrote at 2004-5-15 13:04 -0400:
...
Dieter, do you think you can read this patch and give a thumbs up or
down on it?
The patch looks good.
On a different subject, the publisher probably
On Mon, 2004-05-17 at 13:06, Steve Jibson wrote:
I'm sure 'accountType' should have been in the session. Immediately
after a user logs in we populate his session with a bunch of stuff
(including accountType).
What happens when the session expires and he's still logged in?
What I don't
Chris McDonough wrote:
On Mon, 2004-05-17 at 13:06, Steve Jibson wrote:
I'm sure 'accountType' should have been in the session. Immediately
after a user logs in we populate his session with a bunch of stuff
(including accountType).
What happens when the session expires and he's still logged
On Mon, 2004-05-17 at 14:58, Steve Jibson wrote:
We're using ExUserFolder for authentication. We have it set to log
users out after 10 minutes. We have sessions set to expire after 20
minutes. So, in theory, it should never happen.
Are you sure that their auth really does time out after
On 18/05/2004, at 5:42 AM, Chris McDonough wrote:
On Mon, 2004-05-17 at 13:06, Steve Jibson wrote:
Also of note:
1 - After having the system run for 45 minutes, I had 8 similar
errors.
Some were on different web pages and some had different keys that
were causing the error.
2 - I have also
On Mon, 2004-05-17 at 17:52, Michael Dunstan wrote:
Looks like session data can expire prematurely. See attached files for
small changes to the test rig that reports cases where
context.session_data_manager.hasSessionData() is False.
Michael
I think you're right, good eye! The symptoms
There indeed is a minor off-by-one error: it manifests itself as
sessions timing out at most 20 seconds early.
But there is also a deeper issue which involves the fact that a session
data object is not properly removed from an older bucket when it moves
due to being accessed in a later timeslice;
On Thu, 2004-05-13 at 18:11, Tres Seaver wrote:
Chris McDonough wrote:
Largely due to Michael I believe I have isolated and fixed every
reported sessioning error except this
(still-difficult-to-reproduce-but-definitely-still-existing) KeyError
bug in temporary storage. I can let the test
Chris,
Okay, correct me if I'm wrong. This means the big ugly SESSION problem
his completely fixed. If so, you are my new best friend! (whether you
like it or not).
Anyway, I'll put your updates (TemporaryStorage.py and Transience.py)
on a couple of my customer's systems (that have been
On Sat, 2004-05-15 at 23:11, Steve Jibson wrote:
Chris,
Okay, correct me if I'm wrong. This means the big ugly SESSION problem
his completely fixed. If so, you are my new best friend! (whether you
like it or not).
Well, I'm afraid I will need to correct you. ;-) There is one more
Chris McDonough wrote:
On Sat, 2004-05-15 at 23:11, Steve Jibson wrote:
Chris,
Okay, correct me if I'm wrong. This means the big ugly SESSION problem
his completely fixed. If so, you are my new best friend! (whether you
like it or not).
Well, I'm afraid I will need to correct you. ;-) There
On Sat, 2004-05-15 at 23:55, Steve Jibson wrote:
quite yet been vetted (see earlier posts in this thread regarding
Publish.py). This should work itself out over the next week or so I
suspect.
Relatively speaking, this is only a minor concern. It just means I
shouldn't try to access
Chris McDonough wrote:
Largely due to Michael I believe I have isolated and fixed every
reported sessioning error except this
(still-difficult-to-reproduce-but-definitely-still-existing) KeyError
bug in temporary storage. I can let the test rig run for several hours;
it happens maybe once every
Chris McDonough wrote:
On Wed, 2004-03-10 at 19:30, Paul Winkler wrote:
I suggested doing a bug day as part of the pycon z2 sprint,
but we haven't really discussed the various sprint proposals
in depth yet.
Since you and I are going to be there on Saturday and Sunday, why don't
we do this on
Saturday Mar 20, Sun Mar 21...
On Thu, 2004-03-11 at 06:54, Chris Withers wrote:
Chris McDonough wrote:
On Wed, 2004-03-10 at 19:30, Paul Winkler wrote:
I suggested doing a bug day as part of the pycon z2 sprint,
but we haven't really discussed the various sprint proposals
in depth
On Wed, 10 Mar 2004 17:50:41 -0500
Chris McDonough [EMAIL PROTECTED] wrote:
Nevermind. http://zope.org/Collectors/Zope/789 and
http://zope.org/Collectors/Zope/786
The bug neglector is really living up to its name lately (not pointing
fingers, mea culpa).
'Bout time fer a bug day I
On Wed, Mar 10, 2004 at 06:14:30PM -0500, Casey Duncan wrote:
On Wed, 10 Mar 2004 17:50:41 -0500
Chris McDonough [EMAIL PROTECTED] wrote:
Nevermind. http://zope.org/Collectors/Zope/789 and
http://zope.org/Collectors/Zope/786
The bug neglector is really living up to its name lately
27 matches
Mail list logo
