mina component lifecycles

[peter royal <pr...@apache.org>]

I think we mainly need a 'disposal' phase, for when things are no  
longer needed. init/start/stop could be added, but I'm not sure we  
need them yet.

When running "containerless", we can have a BasicLifecycleManager.  
This is just a convenience to do disposal on a bunch of components in  
one shot.

to take the sumup.Client example:

         ThreadPoolFilter ioThreadPoolFilter = new ThreadPoolFilter();
         ThreadPoolFilter protocolThreadPoolFilter = new  
ThreadPoolFilter();
         IoConnector connector = new SocketConnector();
         connector.getDefaultConfig().getFilterChain().addFirst(
                 "ioThreadPool", ioThreadPoolFilter );
         connector.getDefaultConfig().getFilterChain().addLast(
                 "protocolThreadPool", protocolThreadPoolFilter );

users would then also do

	BasicLifecycleManager lm = new BasicLifecycleManager();

	lm.add( ioThreadPoolFilter );
	lm.add( protocolThreadPoolFilter );
	lm.add( connector );

and then, when the system is done:

	lm.dispose();

.. for users integrating into a container, they would not use  
BasicLifecycleManager at all. the lifecycles would be managed by the  
container.

thoughts?

-pete

	
-- 
proyal@apache.org - http://fotap.org/~osi

Re: mina component lifecycles

[Trustin Lee <tr...@gmail.com>]

Hi Peter,

On 3/5/06, peter royal <pr...@apache.org> wrote:
>
> I'd say that IoFilterLM could go away.. and take Michael's idea and
> wrap what the IoFilterLCM does in a decorator that can wrap IoFilter
> instances when people wish to have the in-use refcounting and
> variable occurrences of Init/Destroy.


I completely agree with you.  So here's the summary:

* Remove init() and destroy() from IoFilter.
* Create a utility class which provides init() and destroy() by decorating
existing IoFilter implementation.

WDYT?  Do all of us agree with this?  :D

PS: I post this message via mailing list because JIRA is down right now :(

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Re: mina component lifecycles

[peter royal <pr...@apache.org>]

On Mar 3, 2006, at 11:56 PM, Trustin Lee wrote:
> On 3/4/06, peter royal <pr...@apache.org> wrote:
>
>>         lm.add( connector );
>
>
> Interesting.  For now all I/O threads start and stop automatically  
> just like
> we init and destroy filters.  Will this also become a problem?  It  
> may cause
> high latency when the first session is ceated.  I thought I/O threads
> (acceptors, connectors and SocketIoProcessors) are OK to exclude  
> from the
> managee list because we can control it very easily and destroy  
> process is
> very simple and light.

ya, IO threads would be fine.. I typed that late last night and just  
threw all the components in there :)

>> and then, when the system is done:
>>
>>         lm.dispose();
>
>
> This sounds good.  So the modified IoFilterLifecycleManager calls  
> init() but
> doesn't call destroy() at all, and destroy() will be invoked by
> BasicLifecycleManager?  Then what happens to the filters  
> instantiated for
> each session?

I'd say that IoFilterLM could go away.. and take Michael's idea and  
wrap what the IoFilterLCM does in a decorator that can wrap IoFilter  
instances when people wish to have the in-use refcounting and  
variable occurrences of Init/Destroy.
-pete
-pete

-- 
proyal@apache.org - http://fotap.org/~osi

Re: mina component lifecycles

[Trustin Lee <tr...@gmail.com>]

Hi Peter,

Thanks for your active feedback!

On 3/4/06, peter royal <pr...@apache.org> wrote:

>         lm.add( connector );


Interesting.  For now all I/O threads start and stop automatically just like
we init and destroy filters.  Will this also become a problem?  It may cause
high latency when the first session is ceated.  I thought I/O threads
(acceptors, connectors and SocketIoProcessors) are OK to exclude from the
managee list because we can control it very easily and destroy process is
very simple and light.


and then, when the system is done:
>
>         lm.dispose();


This sounds good.  So the modified IoFilterLifecycleManager calls init() but
doesn't call destroy() at all, and destroy() will be invoked by
BasicLifecycleManager?  Then what happens to the filters instantiated for
each session?

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6