IoFilter lifecycles

[peter royal]

On Mar 3, 2006, at 1:36 PM, Niklas Therning 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.

chain. (I thought before there was a filter chain that was  below the

is only one now, and it is tied to the session?

It keeps wanting to destroy itself when attached to the session filter session, and then the session filter chain, but it appears that there

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.

Yes, there are separate chains now for each session. When a new session

k, that confirm what I saw in the code, thanks :)

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).

ah, ok.. I haven't been paying enough attention to the jira issues floating about.. what JDK are you using? this deadlock makes me want to make a ThreadPoolFilter that just delegates to a ThreadPoolExecutor, <http:// java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ ThreadPoolExecutor.html>, but that's Java5 only... Java 5 comes with so many nice synchronization primitives that would alleviate a lot of the synchronization going on in the code..

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

be an issue anymore.

init()/destroy() on those filters which require so DIRMINA-169 wouldn't

-pete

--
[EMAIL PROTECTED] - http://fotap.org/~osi

agreed! (i'm setting it up using Picocontainer..) .. i'm curious as to how many people are using MINA outside of another framework that can provide lifecycle support? .. to step back a bit further, some filters will be session-scoped wrt lifecycle, and some will be application-scoped.. when building the list of filters to be applied to a session, why not built a set of IoFilterFactories? that way the lifecycle aspect can be passed off to another component.. when a session is closed, the filter instance of just returned to the factory.. an ApplicationScopeIoFilterFactory wouldn't do anything when the session is closed, it would wait for app shutdown, and a PerSessionIoFilterFactory would then have an opportunity to destroy the filter right there.. .. more than happy to code up some of these ideas if they are amiable to the team.

smime.p7s
Description: S/MIME cryptographic signature