You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by peter royal <pr...@apache.org> on 2006/03/03 18:24:05 UTC
properly using the ThreadPoolFilter in the trunk
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?
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:
"Server-2" prio=5 tid=0x00530870 nid=0x182f000 in Object.wait()
[0xf1519000..0xf151aad0]
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1121)
- locked <0x070d0668> (a org.apache.mina.filter.ThreadPoolFilter
$Worker)
at org.apache.mina.filter.ThreadPoolFilter.destroy
(ThreadPoolFilter.java:209)
at
org.apache.mina.common.support.IoFilterLifeCycleManager.callDestroyIfNec
essary(IoFilterLifeCycleManager.java:214)
at org.apache.mina.common.support.AbstractIoFilterChain.deregister
(AbstractIoFilterChain.java:363)
at org.apache.mina.common.support.AbstractIoFilterChain.remove
(AbstractIoFilterChain.java:295)
- locked <0x070e1738> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain.clear
(AbstractIoFilterChain.java:304)
- locked <0x070e1738> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain
$2.sessionClosed(AbstractIoFilterChain.java:168)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed
(ProtocolCodecFilter.java:165)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.ThreadPoolFilter.processEvent
(ThreadPoolFilter.java:687)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents
(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run
(ThreadPoolFilter.java:376)
"Server-3" prio=5 tid=0x00530fb0 nid=0x180e800 in Object.wait()
[0xf1417000..0xf1418ad0]
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1121)
- locked <0x070d0668> (a org.apache.mina.filter.ThreadPoolFilter
$Worker)
at org.apache.mina.filter.ThreadPoolFilter.destroy
(ThreadPoolFilter.java:209)
at
org.apache.mina.common.support.IoFilterLifeCycleManager.callDestroyIfNec
essary(IoFilterLifeCycleManager.java:214)
at org.apache.mina.common.support.AbstractIoFilterChain.deregister
(AbstractIoFilterChain.java:363)
at org.apache.mina.common.support.AbstractIoFilterChain.remove
(AbstractIoFilterChain.java:295)
- locked <0x070d0718> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain.clear
(AbstractIoFilterChain.java:304)
- locked <0x070d0718> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain
$2.sessionClosed(AbstractIoFilterChain.java:168)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed
(ProtocolCodecFilter.java:165)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.ThreadPoolFilter.processEvent
(ThreadPoolFilter.java:687)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents
(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run
(ThreadPoolFilter.java:376)
"Server-4" prio=5 tid=0x005311f0 nid=0x182f400 in Object.wait()
[0xf159a000..0xf159bad0]
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1121)
- locked <0x070d08f8> (a org.apache.mina.filter.ThreadPoolFilter
$Worker)
at org.apache.mina.filter.ThreadPoolFilter.destroy
(ThreadPoolFilter.java:209)
at
org.apache.mina.common.support.IoFilterLifeCycleManager.callDestroyIfNec
essary(IoFilterLifeCycleManager.java:214)
at org.apache.mina.common.support.AbstractIoFilterChain.deregister
(AbstractIoFilterChain.java:363)
at org.apache.mina.common.support.AbstractIoFilterChain.remove
(AbstractIoFilterChain.java:295)
- locked <0x070d0a68> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain.clear
(AbstractIoFilterChain.java:304)
- locked <0x070d0a68> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain
$2.sessionClosed(AbstractIoFilterChain.java:168)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed
(ProtocolCodecFilter.java:165)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.ThreadPoolFilter.processEvent
(ThreadPoolFilter.java:687)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents
(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run
(ThreadPoolFilter.java:376)
"Server-1" prio=5 tid=0x005303e0 nid=0x180ec00 in Object.wait()
[0xf1315000..0xf1316ad0]
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1121)
- locked <0x070d0668> (a org.apache.mina.filter.ThreadPoolFilter
$Worker)
at org.apache.mina.filter.ThreadPoolFilter.destroy
(ThreadPoolFilter.java:209)
at
org.apache.mina.common.support.IoFilterLifeCycleManager.callDestroyIfNec
essary(IoFilterLifeCycleManager.java:214)
at org.apache.mina.common.support.AbstractIoFilterChain.deregister
(AbstractIoFilterChain.java:363)
at org.apache.mina.common.support.AbstractIoFilterChain.remove
(AbstractIoFilterChain.java:295)
- locked <0x070d0c88> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain.clear
(AbstractIoFilterChain.java:304)
- locked <0x070d0c88> (a
org.apache.mina.transport.socket.nio.support.SocketFilterChain)
at org.apache.mina.common.support.AbstractIoFilterChain
$2.sessionClosed(AbstractIoFilterChain.java:168)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed
(ProtocolCodecFilter.java:165)
at
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClos
ed(AbstractIoFilterChain.java:453)
at org.apache.mina.common.support.AbstractIoFilterChain.access$600
(AbstractIoFilterChain.java:52)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl
$1.sessionClosed(AbstractIoFilterChain.java:742)
at org.apache.mina.filter.ThreadPoolFilter.processEvent
(ThreadPoolFilter.java:687)
at org.apache.mina.filter.ThreadPoolFilter$Worker.processEvents
(ThreadPoolFilter.java:421)
at org.apache.mina.filter.ThreadPoolFilter$Worker.run
(ThreadPoolFilter.java:376)
.. that is, I have 4 threads that all think that they should be
destroying the ThreadPoolFilter, and effectively locking my stuff up.
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..
.. 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?
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: IoFilter lifecycles
Posted by peter royal <pr...@apache.org>.
On Mar 4, 2006, at 12:38 AM, Trustin Lee wrote:
> what i'd like to see, is a ThreadPoolFilter that just manages with
>> reading in events and putting them into per-session queues, and then
>> we can plug in threading strategies.. I may plug in a
>> ThreadPoolExecutor strategy, others could use the existing leader/
>> follower strategy.
>
>
> It will be very great if we can, but we also should design the
> thread pool
> interface so it can cover both normal and L-F thread pools. I
> think we can
> do this. You interested? :)
I'll see what I can do :)
> Actually, we can just remove init()
> and destroy() and let IoFilter imeplementations choose when to init
> and
> destroy itself (e.g. a filter could destroy itself when it is
> removed from
> all session filter chains. Without init() and destroy() everything
> becomes
> very simple and we don't need to do lifecycle management globally
> at all.
> Does this make sense?
Makes sense, I like it!
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: IoFilter lifecycles
Posted by Trustin Lee <tr...@gmail.com>.
On 3/4/06, peter royal <pe...@pobox.com> wrote:
>
> .. but for thread pools, has testing been done to show that the
> Leader-Follower pattern is more efficient than a "standard" thread
> pool where a single thread dispatches events to a thread in the pool?
It's not a matter of performance, it's a matter of the order of events. The
normal thread pools cannot guarentee the order of events and messages.
(sorry if this has been gone over before...) .. i read the following
> thread on concurrency-interest, <http://altair.cs.oswego.edu/
> pipermail/concurrency-interest/2005-June/001566.html> (as well as
> some of the paper linked in the TPF docs), and as I understand it,
> the primary benefit from the leader-follower pattern is to minimize
> context switches.
True, but that's another aspect.
what i'd like to see, is a ThreadPoolFilter that just manages with
> reading in events and putting them into per-session queues, and then
> we can plug in threading strategies.. I may plug in a
> ThreadPoolExecutor strategy, others could use the existing leader/
> follower strategy.
It will be very great if we can, but we also should design the thread pool
interface so it can cover both normal and L-F thread pools. I think we can
do this. You interested? :)
I think MINA's strength is pushing packets around.. it shouldn't try
> to invent its own lifecycle management, others have done that
> already.. ideally, the core would just declare that things *have* a
> lifecycle, but not actually *manage* it. we can have a basic-
> lifecycle module that users that wish to use a "standalone" mina can
> use, but then spring/pico/hivemind/geronimo/whatever users could also
> just bridge the lifecycle requirements of MINA components on to the
> lifecycle management that the hosting container will provide.
I agree with you. What I want to say is we also need to take care of users
who don't use container frameworks yet. This means we have to provide
minimal life cycle management as a built-in feature. The question is 'where
to stop'. For example, I think we need to manage I/O threads and selectors
automatically at least due to the reason I mentioned in the other thread.
> 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 don't agree here. I have some IoFilter's that are used on a per-
> session basis, and then only for part of the duration of the session.
> The ability to dynamically add and remove filters is an incredible
> capability, I would not want to backtrack on the possibilities here.
>
> For filter lifecycle, how about just adding two methods:
>
> IoFilter.filterAdded( IoSession )
> IoFilter.filterRemoved( IoSession )
>
> then, individual IoFilter instances can manage their lifecycle as
> they see fit.
Yes, I thought about this too before. Actually, we can just remove init()
and destroy() and let IoFilter imeplementations choose when to init and
destroy itself (e.g. a filter could destroy itself when it is removed from
all session filter chains. Without init() and destroy() everything becomes
very simple and we don't need to do lifecycle management globally at all.
Does this make sense?
I agree that more people need to speak up. I'm pushing my interests,
> and what I think would benefit others.. but of course I can't know
> for certain what others want :)
Yep. People, let's speak up! :)
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
Re: IoFilter lifecycles
Posted by peter royal <pe...@pobox.com>.
On Mar 3, 2006, at 7:13 PM, Trustin Lee wrote:
> On 3/4/06, peter royal <pr...@apache.org> 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.
as an aside, i'd like to make the concurrency bits pluggable so that
Java5-native things can be used instead on that platform..
.. but for thread pools, has testing been done to show that the
Leader-Follower pattern is more efficient than a "standard" thread
pool where a single thread dispatches events to a thread in the pool?
(sorry if this has been gone over before...) .. i read the following
thread on concurrency-interest, <http://altair.cs.oswego.edu/
pipermail/concurrency-interest/2005-June/001566.html> (as well as
some of the paper linked in the TPF docs), and as I understand it,
the primary benefit from the leader-follower pattern is to minimize
context switches.
with that said, looking at how the TheadPoolFilter and the
ThreadPoolExecutor work, they are both essentially the same.. One
thread submits the task to a queue, and another thread takes the
event and handles it. am i missing something?
what i'd like to see, is a ThreadPoolFilter that just manages with
reading in events and putting them into per-session queues, and then
we can plug in threading strategies.. I may plug in a
ThreadPoolExecutor strategy, others could use the existing leader/
follower strategy.
> 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..
I use one that MINA doesn't directly support now (Picocontainer).
Since MINA doesn't offer a main() method, users *must* have some sort
of lifecycle around the whole system, however primitive it may be.
I think MINA's strength is pushing packets around.. it shouldn't try
to invent its own lifecycle management, others have done that
already.. ideally, the core would just declare that things *have* a
lifecycle, but not actually *manage* it. we can have a basic-
lifecycle module that users that wish to use a "standalone" mina can
use, but then spring/pico/hivemind/geronimo/whatever users could also
just bridge the lifecycle requirements of MINA components on to the
lifecycle management that the hosting container will provide.
> 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 don't agree here. I have some IoFilter's that are used on a per-
session basis, and then only for part of the duration of the session.
The ability to dynamically add and remove filters is an incredible
capability, I would not want to backtrack on the possibilities here.
For filter lifecycle, how about just adding two methods:
IoFilter.filterAdded( IoSession )
IoFilter.filterRemoved( IoSession )
then, individual IoFilter instances can manage their lifecycle as
they see fit.
I will start another thread about global lifecycle of mina components.
> This is just an idea. We need to dig into this issue further and
> ask what
> users think. :)
I agree that more people need to speak up. I'm pushing my interests,
and what I think would benefit others.. but of course I can't know
for certain what others want :)
-pete
--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi
Re: IoFilter lifecycles
Posted by Trustin Lee <tr...@gmail.com>.
On 3/4/06, peter royal <pr...@apache.org> 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
IoFilter lifecycles
Posted by peter royal <pr...@apache.org>.
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.
>>
>> 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.
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
> 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?
.. 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.
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: properly using the ThreadPoolFilter in the trunk
Posted by Niklas Therning <ni...@trillian.se>.
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