mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter royal <peter.ro...@pobox.com>
Subject Re: IoFilter lifecycles
Date Sat, 04 Mar 2006 03:56:15 GMT
On Mar 3, 2006, at 7:13 PM, Trustin Lee wrote:
> On 3/4/06, peter royal <proyal@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 :)


(peter.royal|osi)@pobox.com - http://fotap.org/~osi

View raw message