<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
I switched on every logging option and added a hook to session-removal-hook<BR>
<BR>
(setf hunchentoot::*session-removal-hook* #'(lambda (session)<BR>
(hunchentoot::log-message :info "Session-removal-hook ~A" session))<BR>
(setf hunchentoot::*message-log-pathname* "/home/phil/www/")<BR>
(setf hunchentoot::*log-lisp-errors-p* t)<BR>
(setf hunchentoot::*log-lisp-backtraces-p* t)<BR>
(setf hunchentoot::*log-lisp-warnings-p* t)<BR>
(setf hunchentoot::*lisp-warnings-log-level* :info)<BR>
(setf hunchentoot::*lisp-errors-log-level* :info)<BR>
<BR>
And after about 16 minutes this gem came up in the log<BR>
<BR>
[2010-05-21 17:26:43 [INFO]] Session-removal-hook #<SESSION {A9EB191}><BR>
[2010-05-21 17:26:43 [INFO]] Session-removal-hook #<SESSION {C2F4249}><BR>
<BR>
Attached find the full log for the session.<BR>
<BR>
Could invalid cookies cause a session gc in hunchentoot?<BR>
<BR>
Please advise on how I could track what causes the gc.<BR>
<BR>
Thank you very much for your patience.<BR>
<BR>
<BR>
<BR>
On Fri, 2010-05-21 at 15:03 +0200, Hans Hübner wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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 <<A HREF="mailto:zaries@global.co.za">zaries@global.co.za</A>> 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 <<A HREF="mailto:zaries@global.co.za">zaries@global.co.za</A>> 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
> <A HREF="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</A>
> <A HREF="http://common-lisp.net/mailman/listinfo/tbnl-devel">http://common-lisp.net/mailman/listinfo/tbnl-devel</A>
>
>
> _______________________________________________
> tbnl-devel site list
> <A HREF="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</A>
> <A HREF="http://common-lisp.net/mailman/listinfo/tbnl-devel">http://common-lisp.net/mailman/listinfo/tbnl-devel</A>
>
_______________________________________________
tbnl-devel site list
<A HREF="mailto:tbnl-devel@common-lisp.net">tbnl-devel@common-lisp.net</A>
<A HREF="http://common-lisp.net/mailman/listinfo/tbnl-devel">http://common-lisp.net/mailman/listinfo/tbnl-devel</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>