[hunchentoot-devel] Session Time Out - HELP!

Fri May 21 16:15:18 UTC 2010

Ok, I will try.

Just to put me on the right tract, why would hunchentoot kill ALL
sessions in GC and not just he ones that might have expired because that
is what is happening here?

On Fri, 2010-05-21 at 17:56 +0200, Hans Hübner wrote:

> Phil,
> 
> session garbage collection is triggered (only) during request
> processing as a side effect of creating a new session.  Sessions are
> only deleted when their max idle time has been reached.  Invalid
> session cookies have no influence on the deletion, i.e. if an invalid
> session cookie is detected by Hunchentoot, a new session will be
> created.  Expiry is then only run as a side effect.
> 
> You'll have no option but read session.lisp yourself and try to make a
> better analysis.  You may even find a bug in Hunchentoot, but from my
> perspective, I cannot see anything wrong.  Print statements and
> tracing are your friend.
> 
> -Hans
> 
> On Fri, May 21, 2010 at 17:35, Phil Marneweck <zaries at global.co.za> wrote:
> > I switched on every logging option and added a hook to session-removal-hook
> >
> > (setf hunchentoot::*session-removal-hook* #'(lambda (session)
> > (hunchentoot::log-message :info "Session-removal-hook ~A" session))
> > (setf hunchentoot::*message-log-pathname* "/home/phil/www/")
> > (setf hunchentoot::*log-lisp-errors-p* t)
> > (setf hunchentoot::*log-lisp-backtraces-p* t)
> > (setf hunchentoot::*log-lisp-warnings-p* t)
> > (setf hunchentoot::*lisp-warnings-log-level* :info)
> > (setf hunchentoot::*lisp-errors-log-level* :info)
> >
> > And after about 16 minutes this gem came up in the log
> >
> > [2010-05-21 17:26:43 [INFO]] Session-removal-hook #<SESSION {A9EB191}>
> > [2010-05-21 17:26:43 [INFO]] Session-removal-hook #<SESSION {C2F4249}>
> >
> > Attached find the full log for the session.
> >
> > Could invalid cookies cause a session gc in hunchentoot?
> >
> > Please advise on how I could track what causes the gc.
> >
> > Thank you very much for your patience.
> >
> >
> >
> > On Fri, 2010-05-21 at 15:03 +0200, Hans Hübner wrote:
> >
> > Phil,
> >
> > did you make sure that it is actually Hunchentoot that "kills" your
> > sessions?  Does SESSION-TOO-OLD-P ever return T for a session that
> > you've been using?  Did you do some analysis on the Cookies headers
> > that your server receives?  Maybe your frontend somehow messes up the
> > cookies.  Did you look at the Hunchentoot log file?  Any anomalies?
> > Does it report something about sessions?  Try disabling the session
> > garbage collector completely by making it return without doing
> > anything.
> >
> > >From what you write I have the impression that the problem is not
> > within Hunchentoot itself.
> >
> > -Hans
> >
> > On Fri, May 21, 2010 at 13:12, Phil Marneweck <zaries at global.co.za> wrote:
> >> Well after running fine for a while hunchentoot is again re-setting
> >> sessions
> >> at arbitrary intervals.
> >>
> >> I have closed down my lisp instance serveral times today and restarted
> >> everything. Everything will work for a while (5 to 45 minutes) and then
> >> fall
> >> apart. Once hunchentoot has killed sessions once, it does so every couple
> >> of
> >> minutes, some times under a minute.
> >>
> >> I have checked my code again looking for a place that I might be killing
> >> the
> >> sessions or setting the session to nil in any way but I have no such code.
> >>
> >> I set the following before creating any acceptors:
> >>
> >> (setf hunchentoot::*session-gc-frequency* nil)
> >> (setf hunchentoot::*session-max-time* 36000)
> >> (setf hunchentoot::*use-user-agent-for-sessions* nil)
> >>
> >> hunchentoot::*use-remote-addr-for-sessions* reports NIL
> >>
> >> I added a check to see what the (session-db *my-acceptor*) reports when I
> >> say hunchentoot "resets sessions" and it reports NIL. Before a reset
> >> (session-db *my-acceptor*) reports (8 .#).
> >>
> >> The only other thing that I can think might have an effect is that the
> >> site
> >> uses ssl but hunchentoot is not hangling the ssl I am forwarding from
> >> nginx
> >> to hunchentoot.
> >>
> >> Any suggestions?
> >>
> >>
> >>
> >> On Thu, 2010-05-20 at 11:23 +0200, Edi Weitz wrote:
> >>
> >> On Thu, May 20, 2010 at 6:41 AM, Phil Marneweck <zaries at global.co.za>
> >> wrote:
> >>
> >>> Thanx again for the help.
> >>
> >> You're welcome... :)
> >>
> >>> PS: How about some cross references in the documentation for
> >>> *session-gc-frequency*, *session-max-time* and
> >>> *use-remote-addr-for-sessions* just as a heads up for other people that
> >>> might stumble into this?
> >>
> >> Well, they are all mentioned in the same short chapter about sessions,
> >> and *use-remote-addr-for-sessions* is by default set to NIL.  One
> >> should assume that users setting this value to T know what they're
> >> doing.  Besides, I don't see any specific relation between, e.g.,
> >> *session-gc-frequency* and *use-remote-addr-for-sessions*.
> >>
> >> Edi.
> >>
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>
> >>
> >> _______________________________________________
> >> tbnl-devel site list
> >> tbnl-devel at common-lisp.net
> >> http://common-lisp.net/mailman/listinfo/tbnl-devel
> >>
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20100521/34955cf7/attachment.html>