As I mentioned in an earlier thread, I have been doing performance testing
of our application, including the MINA performance.
One thing we did was replace the MINA ThreadPoolFilter with our own thread
pool filter that uses the Java 5 ThreadPoolExecutor. The main reason for
this was not just so that we could use the Java 5 class but so that we
could avoid the behaviour of the current thread pool filter which doesn't
treat filterWrite() as an event. We wanted to be able to put a "read
filter" at the start of the filter chain so that reads would be handled by
that filter, and a "write filter" at the end of the filter chain that was
only interested in the filterWrite() method. By doing this, we could ensure
the message decoding and encoding was handled by separate threads which we
hoped would improve things on the 8 and 16 way boxes we predominantly use.
We only just completed coding our filter, but on our initial tests we are
seeing roughly 25%-30% improvement in throughput using our thread pool
filter compared with the MINA one. It would be interesting to write a
leader follower thread pool executor to see how that compares too.
It is wrong to suggest that the ThreadPoolFilter and ThreadPoolExecutor are
"just the same" however. The key thing that the thead pool filter needs to
do is ensure that the ordering of events is preserved, i.e you cannot have
two threads executing events on behalf of the same IoSession.
I am interested in the discussion about DIRMINA-169 since it may affect my
filter although I haven't examined the locking in the
IoFilterLifecycleManager yet. What I do is have a reference counting
wrapper around the ExecutorService and use the init() and destroy() methods
to increment and decrement the ref count, creating and destroying the pool
appropriately. The ref count check and the pool creation/destruction are
done in a synchronized block.
I certainly think that the lifecycle methods are important and I don't see
how they relate to any containers you might be using. I also think that the
current idea of the DefaultIoFilterChainBuilder is an elegant one, that
allows you to have per session and per acceptor filters quite easily.
Regarding Java 5 support and whether java.util.concurrent should be used, I
certainly think it makes sense to support use of Java 5 concurrency
classes. People who are writing network servers are often interested in
maximum performance therefore they will not be using 1.4 JVMs. Perhaps
using the concurrent backport would enable two builds to be created - one
for 1.4 and another for 1.5 (you do have to change the imports but I am
sure it could be automated). This would enable use of some of the
concurrent data structures. For example, one thing we noticed was some
contention in ByteBuffer since access to the stacks were synchronized. I
change this to use the ConcurrentLinkedQueue instead of the MINA Queue and
the contention was reduced.
Robert
peter royal
<[EMAIL PROTECTED] To:
[email protected]
x.com> cc:
Subject: Re: IoFilter
lifecycles
04/03/2006 03:56
Please respond to
mina-dev
On Mar 3, 2006, at 7:13 PM, Trustin Lee wrote:
> 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.
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
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
