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