mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@archean.fr>
Subject Re: [mina 3.0] Idleness detection
Date Mon, 22 Feb 2010 09:44:17 GMT
Le Mon, 22 Feb 2010 10:01:48 +0100,
Emmanuel Lécharny <elecharny@apache.org> a écrit :

> 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
> >
> >
> >
> 
> 
> 

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.
-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr

Mime
View raw message