Well after driving myself and this mailing list nuts with this issue it turns out it is my bad...
A new colleague of mine (one I am training) uploaded a piece of code to our server without checking it into our repository, this piece of offending code had a hunchentoot::reset-sessions in it and I have been greping againts the local code base to find any resets , after adding some more logging to sessions.lisp on the server i was able to find the offending code on the server.
I appologise for the frantic messages and thank the members of this list for there patience and help ... once again!!!
By the way thanx for the wonderful work you do on huncentoot, we appreciate every bit.
Yours Humbly ....*grovel* ...*grovel*
On Fri, 2010-05-21 at 19:03 +0200, Phil Marneweck wrote:
Ok thanx put some log entries in there and will report back.
On Fri, 2010-05-21 at 18:40 +0200, Hans Hübner wrote:
On Fri, May 21, 2010 at 18:15, Phil Marneweck zaries@global.co.za wrote:
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?
(defun session-gc () "Removes sessions from the current session database which are too old - see SESSION-TOO-OLD-P." (with-session-lock-held ((session-db-lock *acceptor*)) (setf (session-db *acceptor*) (loop for id-session-pair in (session-db *acceptor*) for (nil . session) = id-session-pair when (session-too-old-p session) do (funcall *session-removal-hook* session) else collect id-session-pair))) (values))
i.e. you need to read the source.
-Hans
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