mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Link <michael.l...@onlinehome.de>
Subject IoFilter lifecycles
Date Sat, 04 Mar 2006 14:37:15 GMT
I don't know if this helps at all, but here just my thoughts ...

As I understood the IoFilterLifeCycleManager manages all IoFilters and 
puts them together in IoFilterChains when a session is opened. When all 
IoFilterChains (and thus Sessions) are gone it will clean up the 
IoFilters by calling their destroy-Method. When a new session is opened 
the init-Method of the chained IoFilters are called again and so on. I 
like this self-management of MINA although in the case of the 
ThreadPoolFilter it seems too much.

My thoughts were: what about having an DelegatedIoFilter (or something 
with a similar name :-) that delegates all calls to the wrapped IoFilter 
except the LifeCycle-Calls init and destroy. For example:

    public class DelegatedIoFilter implements IoFilter {
        private IoFilter _delegate;
        private boolean _delegateIsInitialized = false;
        private boolean _destroyDelegate = false;
        
        public DelegatedIoFilter(IoFilter delegate) {
            _delegate = delegate;
        }
        
        public void init() throws Exception {
            if(!_delegateIsInitialized) {
                _delegate.init();
                _delegateIsInitialized = true;
            }
        }

        public void destroy() throws Exception {
            if(_delegateIsInitialized && _destroyDelegate) {
                _delegate.destroy();
                _delegateIsInitialized = false;
            }
        }
        
        public void setDestroyDelegate(boolean destroyDelegate) {
            _destroyDelegate = destroyDelegate;
        }
        
        public boolean getDestroyDelegate() {
            return _destroyDelegate;
        }

        public void onPreAdd(IoFilterChain arg0, String arg1, NextFilter 
arg2) throws Exception {
            _delegate.onPreAdd(arg0, arg1, arg2);
        }
    ....

By setting the DestroyDelegate-Property the user/the container can 
manually tell the filter to pass through the destruction life-cycle 
call. Now when I configure the ChainBuilder I put such an 
DelegatedIoFilter into the chain which wraps the ThreadPoolFilter.

    ThreadPoolFilter threadPoolFilter = new ThreadPoolFilter();
    threadPoolFilter.setMaximumPoolSize(10);
    DelegatedIoFilter unmanagedDelegateIoFilter = new 
DelegatedIoFilter(threadPoolFilter);
    chain.addFirst( "ThreadPool", unmanagedDelegateIoFilter );

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.

Does this make any sense ? I don't know :-)

Michael


Mime
View raw message