Some additional info:
I am running the latest sbcl, hunchentoot and related code from clbuild as of Monday the 17th and my server is a virtual ubuntu 9.4
On Fri, 2010-05-21 at 13:12 +0200, Phil Marneweck 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