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 now and plan to spend some time this morning going through them.

Anyway, it appears that I was wrong when I said that the problem doesn't show up when I use FileStorage (although it does seem to happen less frequently -- but who can be sure of anything at this point?).

In answer to your questions earlier, Chris, we set up the user session at login time because we make the user answer some questions at login time that determine which portions of the interface to present to him/her. For example, using the same login id and password, a user may choose to login as an administrator or as a normal user. We store this choice and other info based on this choice in the session. Also, we don't rely on the browser to time out the authentication cookie. Once a user authenticates with ExUserFolder, ExUserFolder keeps their credentials in a cache until they have been inactive for 10 minutes (the timer resets with each cache hit). If their credentials are not in the cache, rather than looking them up again, the user is logged out and must re-authenticate. It seems like a reasonable way to handle logins and sessions.

In addition to going through log files, I will spend some more time today making sure we're not doing something stupid in our app.

Thanks again (to Chris, Michael, Alex and everyone else who has lost sleep over this session stuff). I'll keep you posted on any new information I find.

Steve

Chris McDonough wrote:
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 when it "moves"
due to being accessed in a later timeslice; the symptom only appears
when a browser id is "reused" to start a session after it was used to
start an older one that had timed out normally.  I've got almost no clue
why this happens at this point, but I'm working on it.  Ugh.  This is
almost certainly what Steve is experiencing.


I take that back.  Actually, I think I was just reading the test results
and debug output wrong.  It appears to be operating normally except for
the off-by-one problem (which is minor).  I need to jack up the tests to
do some comparisons of data values; currently I'm just testing to ensure
that *something* is in the session.. I need to test if the "right" thing
is in the session over time.

- C



_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to