mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Idle management
Date Tue, 24 Jan 2012 12:31:02 GMT
On 1/24/12 12:53 PM, Julien Vermillard wrote:
> Hi,

> Actually in MINA1/2 the idle is computed each second by scanning *all*
> session of a service. If you have a large number of session, it could
> create some student latency in the selector loop.

yes, not good...
> For trying to keep the scanning a bit more lightweight, I was thinking
> about another solution :
> For each session read/write event :
> * we calculate what is the supposed future idle date
> * we round it at the next second
> * we store a reference to this session in a per Selector map like :
> Map<long /*timestamp*/, Set<IoSession>>  , the long is the timestamp of
> the idle time (rounded at the second), this Map is an index poiting to
> the list of session possibly Idle by time range
We could also use an array of int, assuming we know what could be the 
maximum idle time. For instance, if we know that no session can be idle 
for more than, say, one hour, then an array of 3600 sets is needed.

This circular array won't take a lot of memory.

Each element in this array will point to a set of session supposed to TO 
in x seconds from the current time.

Once we have processed all the sessions at the current time, we move the 
counter forward for the next processing.

Obviously, if it takes more than one second to process all the idle 
sessions for a specific second, then we will have to process the next 
second too.

Here is an example with a max idle time of 10 minutes

               +--- Current time
| 0 | 1 |   | T |T+1|   |599|
               |   |
               |   +--> { S2, S7, S12...} (sessions that will TO in one 
               +------> { S5, S6, S8...} (sessions that are idle for the 
maximum configured delay )

At T, we will process S5, S6, S8.

If at the same time, we have a session (say, S2) that has a read/write 
action done, then it will be removed from the T+1 slot and moved to the 
(T+1 + idleDelay) mod 600 position in the array, so that during the next 
second, at T+1, the S2 session won't be present in the set.

That also means we must store the position of each session in this 
array, in order to easily removed them from this slot.

If for any reason we take more than one second to process the idle 
session (or if the R/W processing took more than one second, then we 
must also process the sessions that have became idle since the last time 
we processed them. Ie, if we process the idle session at T, we perfectly 
may not process the idle session at T+1, but only at, say, T+5. In this 
case, we must also process T+1, T+2, T+3 and T+4 idle sessions.

So the IoProcessor must keep a track of the last time we processed the 
idle sessions (here, T)

> * we cleanup the previous idle reference (could be stored in the 
> session) Idle checker thread : 

> * for each second, look in the Map the session possibly idle for this 
> timestamp

> * check the session and fire idle event if needed 

> * delete the map entry 

> This algorithm will add a bit more pressure at the R/W event, but will 
> probably perform a lot better with a huge amount of slow session. the 
> idle event ill come from another thread and won't be synched with r/w 
> events I'll try to kick-in an implementation of the two solution as 
> plugable filters and try to decide which one is the best idea. Julien 

Sounds good to me.

Emmanuel L├ęcharny

View raw message