You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Julien Vermillard <jv...@gmail.com> on 2012/01/24 12:53:24 UTC
[MINA 3.0] Idle management
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.
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 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
Re: [MINA 3.0] Idle management
Posted by Julien Vermillard <jv...@gmail.com>.
On Tue, Jan 24, 2012 at 1:44 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 1/24/12 1:32 PM, Christian Schwarz wrote:
>>
>> Hello,
>>
>> will it be possible to disable the Idle detection when i don't need it?
>
>
> We should make it optional, absolutely. This should be a parameter of the
> IoProcessor (as an IoProcessor will handle more than one service).
>
>
Hi,
I made a first implementation of the upper idea
(o.a.mina.service.idlechecker) in the trunk, I'm still working on unit
tests.
I actually removed idle both read write event (keeping only read and
write idle event)., because I wasn't able to find a meaningful use
case. If someone know why use this event ?
It stills miss some plumber for making the idle checker implementation
configurable but it won't be hard to add.
Julien
Re: [MINA 3.0] Idle management
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 1/24/12 1:32 PM, Christian Schwarz wrote:
> Hello,
>
> will it be possible to disable the Idle detection when i don't need it?
We should make it optional, absolutely. This should be a parameter of
the IoProcessor (as an IoProcessor will handle more than one service).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Idle management
Posted by Christian Schwarz <ch...@googlemail.com>.
Hello,
will it be possible to disable the Idle detection when i don't need it? In
MINA 2 we have 10 Idle-Checker-Threads if we implement 10 different
Protocols ( one IOService per Protocol). If we dont need them, they are a
wasted resource. So it would be nice to disable the Idle detection.
Re: [MINA 3.0] Idle management
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 1/24/12 12:53 PM, Julien Vermillard wrote:
> Hi,
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
|
v
+---+---+...+---+---+...+---+
| 0 | 1 | | T |T+1| |599|
+---+---+...+---+---+...+---+
| |
| +--> { S2, S7, S12...} (sessions that will TO in one
second)
+------> { 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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com