On 3/4/06, peter royal <[EMAIL PROTECTED]> wrote:
>
> 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..
The thread pool implementation ThreadPoolFilter uses a Leader-Followers
thread pool, which behaves differently from a ThreadPoolExecutor. Moreover,
we have to retain the backward compatibility with JDK 1.4.
> 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.
>
> 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?
But the users who don't use any container frameworks (or use a framework
that mina doesn't support for now), have to manage the lifecycle manually.
Also, this means it introduces another interface that a user has to deal
with if MINA is not used within that framework..
.. 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.
By principle, and IMHO, I think all IoFilter implementations should be able
to be shared among multiple sessions. This means that there's no IoFilter
which has to be instantiated for each session. Even SSLFilter can be shared
now using session attributes.
I think this principle can change of course, but the problem is how. The
problem here is that the life cycle of filters is managed *too*
automatically, especially when the number of session is between 0 and 1.
(This is also the beauty of the life cycle manager.) I think we might be
able to work around this issue by separating the thread which calls
IoFilter.destroy(). For example, we could postpone a call to destroy() for
30 seconds (+ shutdown hook) so it doesn't become a problem for most cases.
This will resolve most issues with deadlock because the call will be
executed in an isolated thread (pool). Another reasonable option would be
like this:
public class ThreadPoolFilter implements IoFilter {
public IoFilter.DestroyMode getDestroyMode() {
return DESTROY_LATER;
}
}
Possible modes would be:
* DestroyMode.IMMEDIATELY (default)
* DestroyMode.SEPARATE_THREAD (spawn a new thread to destroy)
* DestroyMode.TIMEOUT (spawn a new thread. destroy after timeout)
This is just an idea. We need to dig into this issue further and ask what
users think. :)
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
