On Mon, Feb 22, 2010 at 3:14 PM, Julien Vermillard <[email protected]> wrote: > Le Mon, 22 Feb 2010 10:01:48 +0100, > Emmanuel Lécharny <[email protected]> a écrit : > >> Forwarded to the ML >> >> On Mon, Feb 22, 2010 at 1:56 PM, Emmanuel >> Lécharny<[email protected]> wrote: >> > On 2/22/10 8:56 AM, Ashish wrote: >> >> >> >> On Mon, Feb 22, 2010 at 1:12 PM, Emmanuel >> >> Lecharny<[email protected]> wrote: >> >> >> >>> >> >>> Some thoughts about how to manage Idle sessions : >> >>> >> >>> In order to manage idle sessions, we should use a separated >> >>> thread which will check periodically that the session has been >> >>> used or not. We use a boolean flag which is reset when we read of >> >>> write on this session, and switch to true when we check the >> >>> session idleness : if the flag is already >> >>> true, that means the session has been idle for at least one >> >>> period. >> >>> >> >> >> >> >> >>> >> >>> The thread will be wake up after having slept for the defined >> >>> period (configurable globally), and will check every registered >> >>> sessions. >> >>> >> >> >> >> I did something similar for a cache. Used an ScheduledExecutor to >> >> iterate through entries and decide what to do. >> >> It was ok, the only problem in my case was that I got CPU spikes >> >> each time I iterated, but the num of entries were more than a >> >> million :-) >> >> >> > >> > It's the difference between a system that check everynow and then >> > (like the one we have), or a differed system. Of course, if you >> > have to check millions of elements, that's costly. >> >> >> >> >> >>> >> >>> The flag is named isIdle. It's an AtomicBoolean. >> >>> >> >>> Note : if we want to manage different idle times for different >> >>> sessions we >> >>> need to compute the sleep period for all the followed sessions, >> >>> and also add >> >>> a map of sessions to check accordingly to the periods. IMO, it's >> >>> a bit over >> >>> killing atm. >> >>> >> >> >> >> Ehcache has something similar for cache entries. Each cache entry >> >> has last accessed timestamp and based on that calculation is made. >> >> So if Session doesn't fit the criteria, we can safely leave the >> >> same. Side effect would be that we may not have precise time for >> >> events, it shall be when our Thread iterates through all of them. >> >> the other alternative is to use Timertask, but it has overhead >> >> that we need to kill the task each time the session is accessed >> >> and created a new task. there is a lot of overhead in this >> >> approach, but it works fine. >> >> >> > >> > What I want to avoid is a System.currentTimeMillis() call for >> > every byte read or written on each session, and stored in the >> > session, and also avoid the main thread to get swamped by the >> > idleness detection everytime we have some data coming in or getting >> > out. >> >> >> >> hmm... don't know of any other way as of now :( >> >> Any thoughts on how can we do it ? >> >> >> >> >>> Q: should we manage two different IDLE states ? One for READ nod >> >>> one for WRITE ? Not sure it makes sense... >> >>> >> >> >> >> Not sure if it makes sense, but whatever the case may be.. we >> >> fire a session idle event, and either use a keep-alive >> >> functionality or kill the session. >> >> May be we can start with one event. Could any implementation be >> >> interested in having distinct event? I am not sure >> >> >> > >> > me neither... Let's start with one event, then we can improve it >> > once it's solid. >> > >> > -- >> > Regards, >> > Cordialement, >> > Emmanuel Lécharny >> > www.nextury.com >> > >> > >> > >> >> >> > > The idea of doing that in a (optional) parallel thread, will generate a > CPU peak only each seconds (as actual code) but will avoid calling > System.currentTimeMillis() after every select() call. > > BTW we already got an Idle checker based on thread used for serial > transport and VMPipe. > > It'll be lighter in code and CPu, but at the cost of a thread for each > IoService. > > IMO I think it worth the cost.
Sorry, but taking a step back, so that I understand things :) 1. What's the Cost of calling System.currentTimeMillis()? Is it too costly.. 2. Is the discussion converging that we update a boolean flag upon each access and use that to determine if the session is stale. Julien, will it be possible for you to elaborate a bit on how is it lighter in code & CPU. I don't have insight into these two modules. Sorry for these dumb questions :)
