there's a need for long timeouts in this app but could perhaps be reduced from 6 to 3 hours. the sessions are cookie based using php's 'file' handler and session.cookie_lifetime=0. the server appears to have plenty of free memory and appears not to have swapped in nearly a year of uptime. load averages indicate a pretty quiet server. there are currently 170 kbyte total in 90 serialized session files which is typical and not a memory load. the distribution of modification times doesn't indicate heavy activity: ~20 files in the last 15 minutes and 35 in the last hour. so i think the os can handle this. plus the app ran for 6 years before anyone reported being prematurely logged off. i'm looking for other possibilities: odd browser behavior, network trouble, ... are there any browsers that have configurable cookie handling policy such that they time out a cookie? one web site i use displays this curious message: "For your protection, sessions are open for a limited period of time on our website. Please sign-on again. NOTE: Your browser may also limit secure connection time, and automatically log you out independent of our timeout procedure." that could be referring to browsers timing out an ssl connection. or perhaps the cookie? btw: when you said in your email you wouldn't trust a long gc_maxlifetime, and you would only use a cookie-based solution for long session. did you mean that you wouldn't trust php's cookie-based session handler? and you would use a custom handler instead? On 9/22/09 4:46 PM, "Ralph Deffke" <ralph_deffke@xxxxxxxx> wrote: > Hi Tom, > > in sometimes 2001 I did have incidences with those things, and as I remember > over the past years there where some trouble with operating systems and > stuff. This part is very deep inside the os. I would expect that this is > still to consider. I also would check, if this occurs on very busy/low > memory server. > > If I would programm the garbage collection clean up part, and if the server > is about to run out of memory, I would kill sessions being longer time idle > even when they are not yet as old as it is set in the gc_maxlifetime. This > would be far better then shutting down the whole server just because there a > 100 of idle sessions waiting to get used again. > > as u mention a maxlivetime of 6h I would bet, that this is the problem. I > would not trust such a long lifetime at all. > > If sessions have to be active such a long time, I would see only cooky based > solutions > > let me know, what u did investigate on this. > > ralph_deffke@xxxxxxxx > > > "Tom Worster" <fsb@xxxxxxxxxx> wrote in message > news:C6DEAE55.12CAE%fsb@xxxxxxxxxxxxx >> thank you, Ralph! >> >> i'm going to be bold and assume that tom at punkave dot com is right > despite >> that the report was discarded. >> >> i got a complaint from a client about some users reporting being logged > out >> with rather short periods of inactivity. but session.gc_maxlifetime is set >> to 6 hours so i don't think that's the source of the problem. >> >> >> On 9/22/09 4:17 PM, "Ralph Deffke" <ralph_deffke@xxxxxxxx> wrote: >> >>> Hi Tom, >>> >>> i did find this in the bug reports, its pretty new and should be an > answer. >>> >>> http://news.php.net/php.doc.bugs/2653 >>> >>> ralph_deffke@xxxxxxxx >>> >>> >>> "Tom Worster" <fsb@xxxxxxxxxx> wrote in message >>> news:C6DE9EEE.12C8D%fsb@xxxxxxxxxxxxx >>>> i'm not 100% sure what the manual means when it says... >>>> >>>> session.gc_maxlifetime integer >>>> session.gc_maxlifetime specifies the number of seconds after which data >>> will >>>> be seen as 'garbage' and cleaned up. Garbage collection occurs during >>>> session start. >>>> >>>> what event exactly does the "after which" here refer to? >>>> >>>> i'd like to think that it means that a session is eligible for gc no >>> sooner >>>> than session.gc_maxlifetime seconds after the most recent access (read > or >>>> write) to that session. but it seems dangerously presumptuous to assume >>> that >>>> this is the case. >>>> >>>> what do you take it to mean? >>>> >>>> >>> >>> >> >> > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
