Just some feedback:
*use-remote-addr-for-sessions* was definately the problem, or shall I say my understanding of proxy servers was the problem...well you live and you learn...
Thanx again for the help.
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?
On Wed, 2010-05-19 at 16:41 +0200, Phil Marneweck wrote:
I think the culpret might have been *use-remote-addr-for-sessions* I found some forgotten code that sets it to t. Appologies if this was a wild goose chase...
I have removed it now and will monitor the situation.
Thanx for the help your question about cookies triggered the search for *use-remote-addr-for-sessions*.
Once again sorry if this was a wild goose chase, I feel like a real idiot now....*sigh*
On Wed, 2010-05-19 at 16:10 +0200, Edi Weitz wrote:
If it times out after 15 minutes, I'd guess this has nothing to do with session timeouts (as witnessed by session-too-old-p returning NIL) because the default timeout is 30 minutes. Are you sure there's not a problem with cookies somewhere?
On Wed, May 19, 2010 at 3:13 PM, Phil Marneweck zaries@global.co.za wrote:
Thanx for the speedy feedback.
I had to wait to for an opportune moment to shut down hunchentoot on my live server.
Steps
- I restarted it with the *session-gc-frequency* (5000) and
*session-max-time* (3600) values I wanted (before I creating any acceptors).
- Logged into my application and then left the system for 15 minutes, it
timed out when I tried to resume.
- I then placed a trace on HUNCHENTOOT::SESSION-TOO-OLD-P as suggested and
it comes back with a NIL, I pushed the system to make more than 50 new sessions.
- I logged in again and left the system for 15 minutes and again it timed
out when I tried to resume. All this time HUNCHENTOOT::SESSION-TOO-OLD-P is returning NIL.
I know I am grasping at straws now, but could the *SESSION-MAX-TIME* not working have something to do with the fact that the client and the server are in different time zones? If I run the server on my development box the session does not time out like on the server.
Regards Phil
On Wed, 2010-05-19 at 13:13 +0200, Hans Hübner wrote:
Phil,
are you sure that youre new value for *SESSION-MAX-TIME* is used by your sessions? Try tracing HUNCHENTOOT::SESSION-TOO-OLD-P and check the log file for entries saying "Session with ID <id> too old". If you see those messages in the log, or if HUNCHENTOOT::SESSION-TOO-OLD-P returns a true value for a session, your *SESSION-MAX-TIME* change has not been seen by Hunchentoot.
One reason could be that you're changing the value of the global variable after you started Hunchentoot in multi-threaded mode. In that case, the changed value might not be picked up.
Let us know how you proceed.
-Hans
On Wed, May 19, 2010 at 12:46, Phil Marneweck zaries@global.co.za wrote:
Hi
Is there any thing more than *session-gc-frequency* and *session-max-time* that influences session time outs?
Because it does not matter how high I set these values the session keeps on timing out with in a couple of minutes!
Can those values be set at any time or do they have to be set before any acceptors are created?
Any help would be much appreciated this is causing me major pain on a live site.
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