[Zope-dev] Re: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

[Steve Jibson]

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 if you like):

A user logged in and did some stuff then left his browser for almost an 
hour.  When he returned and tried to do more stuff, he was no longer in 
the ExUserFolder's credential cache and his session had expired.  He was 
forced to log in again.  Upon supplying his ID and password, he was sent 
to the "loginSuccess" page.  This is the one that calls our method to 
set up his user session.  The Z2.log shows a 302 result code on this 
page.  His browser had the "loginSuccess" page in cache, so it did not 
request it again and his session was never re-created.

Score one for Chris's suggestion on how we should be setting up the 
user's session.  For now, however, I think I'll just add the 
please-don't-cache-me header stuff to the RESPONSE.


Steve Jibson wrote:
> 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
>