Hi, peter royal wrote: > I'm trying to upgrade my project from the old 0.9.1 API to the new API > that is in the trunk, and I'm having problems with the ThreadPoolFilter. > > It keeps wanting to destroy itself when attached to the session filter > chain. (I thought before there was a filter chain that was below the > session, and then the session filter chain, but it appears that there > is only one now, and it is tied to the session?
Yes, there are separate chains now for each session. When a new session is created several IoFilterChainBuilders will have the opportunity of adding filters to the session's chain. When you call config.getFilterChain().addFirst(..) you will actually add a filter to an IoFilterChainBuilder and not an IoFilterChain like it was before. > > I am only attaching it on the Acceptor side, using: (there's no example > of using it with an Acceptor) > > SocketAcceptorConfig config = new SocketAcceptorConfig(); > > config.setReuseAddress( true ); > config.getFilterChain().addFirst( "ThreadPool", threadPoolFilter ); > > followed by > > acceptor.bind( socketAddress, this, config ); > > .. in a thread dump, I keep seeing: > ... > > > .. that is, I have 4 threads that all think that they should be > destroying the ThreadPoolFilter, and effectively locking my stuff up. You are experiencing DIRMINA-169. I'm struggling with it myself at the moment. > > now, seems to me that constantly destroying the ThreadPoolFilter goes > against what it should be doing.. even if the system is idle, I would > want to have some pooled threads hanging about waiting for some load to > occur.. Right now the ThreadPoolFilter works this way. When it's not used all worker threads will be killed. There's a JIRA issue for specifying a minimumPoolSize which will prevent this from happening (DIRMINA-178). > .. to dig deeper, I'm not sure I like the idea of having IoFilter > lifecycle automatically managed by reference counting of how many times > it is in use.. what if I know better, and I want to have some global > filters I create one at startup, and then destroy at shutdown? I agree. I'm setting up MINA using Spring and I would be perfectly happy with calling init() and destroy() at startup and shutdown using Spring's init-method and destroy-method. If users were responsible of calling init()/destroy() on those filters which require so DIRMINA-169 wouldn't be an issue anymore. > > -pete > /Niklas
