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.
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
In addition to what Hans said, note that there's a per-session slot which you can read and set:
http://weitz.de/hunchentoot/#session-max-time
Edi.
On Wed, May 19, 2010 at 1:13 PM, Hans Hübner hans.huebner@gmail.com 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
Thanx for the speedy feedback.
I had to wait to for an opportune moment to shut down hunchentoot on my live server.
Steps
1. I restarted it with the *session-gc-frequency* (5000) and *session-max-time* (3600) values I wanted (before I creating any acceptors).
2. Logged into my application and then left the system for 15 minutes, it timed out when I tried to resume.
3. 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.
4. 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
Phil,
I don't have an explanation for the behavior that you describe. If I had the problem, I'd look at HTTP header traces (to see if the session cookie has an unexpected expiration), trace some more functions (those that call SESSION-TOO-OLD-P in particular) and the like. The problem could also be related to some header rewriting HTTP proxy in between, but all that is only speculation.
I'd also make an experiment with an out-of-the-box Hunchentoot and the hunchentoot-test package: I'd play around with various *SESSION-MAX-TIME* settings to see whether the behavior is as expected in an isolated setting. From there, I'd try to find out how the production environment differs.
It is certainly possible that Hunchentoot does not work, but I'm kind of reluctant to assume that given the little evidence and analysis that is available in your case.
-Hans
On Wed, May 19, 2010 at 15:13, 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
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
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
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
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.
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
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
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
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
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
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
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
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
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
-
Edi Weitz -
Hans Hübner -
Phil Marneweck