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@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@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@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@common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>>
>> _______________________________________________
>> tbnl-devel site list
>> tbnl-devel@common-lisp.net
>> http://common-lisp.net/mailman/listinfo/tbnl-devel
>>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel@common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel@common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>

_______________________________________________
tbnl-devel site list
tbnl-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel