mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@apache.org>
Subject Fwd: Re: [mina 3.0] Idleness detection
Date Mon, 22 Feb 2010 09:01:48 GMT
Forwarded to the ML

On Mon, Feb 22, 2010 at 1:56 PM, Emmanuel Lécharny<elecharny@apache.org>  wrote:
>  On 2/22/10 8:56 AM, Ashish wrote:
>>
>>  On Mon, Feb 22, 2010 at 1:12 PM, Emmanuel Lecharny<elecharny@gmail.com>
>>    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
>
>
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal



Mime
View raw message