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
