mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Link <michael.l...@onlinehome.de>
Subject Re: IoFilter lifecycles
Date Sun, 05 Mar 2006 09:37:11 GMT
peter royal wrote:
> On Mar 4, 2006, at 9:37 AM, Michael Link wrote:
>> I think this concept would be orthogonal to the Filter-Chain concept; 
>> instead of a chain you have decorator of the filter. And life-cycle 
>> management still works as designed except in the cases where the 
>> user/container explicitly manages the IoFilter. Doesn't solve the 
>> current deadlock problem in ThreadPoolFilter but perhaps adds 
>> something to the discussion about automatic/manual life-cycle 
>> management.
>
> I like this! But I'd invert it -- the behavior of the IoFilterLCM 
> could be a decorator.. If it is desired for an IoFilter to be 
> destroyed when not in use, then prior to adding to the template chain, 
> it would be wrapped in a decorator.
> -pete
>
> --(peter.royal|osi)@pobox.com - http://fotap.org/~osi
>
 From a user point-of-view it's easier to let MINA do all of the LCM 
most of the time. So the decorator should only be necessary when 
user-defined LCM is needed. In the whole I think the init-destroy 
discussion currently only affects the ThreadPoolFilter because it's the 
only one with shared resources. Perhaps the ThreadPoolFilter should be 
split up in two objects, one for the filter implementation and one for 
the pool implementation (I think this was discussed before).

FilterChain
|
ThreadPoolFilter -> ThreadPool (TPF uses TP-Interface which can have 
different implementations L-F-Impl, Java5-Impl ...)
|
LoggingFilter
|
....

Mike

Mime
View raw message