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