finaly we went with a custom cooky handling, however the customers requirements where two days. if u are shure that the server is still the same hardware like it has been 6 years ago then it might be some client stuff, however if there are other applications, pages running (virtual servers) then it would still be to consider. mamory and resource management is deep os. again I wouldn't trust for that amount of session livetime. I dont think, putting it down to three hours would help much. and of course, it could be client side also. Can't you figure out the clients? and keep in mind that a lot of people connect to UMTS rigzt now, these systems deconnect on idle lines and reconect without the users even know it. Also a lot of lines change IP address at midnihgt. cheers ralph_deffke@xxxxxxxx "Tom Worster" <fsb@xxxxxxxxxx> wrote in message news:C6E00521.12D98%fsb@xxxxxxxxxxxxx > 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
