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 aThreadPoolFilter 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 dealwith 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 sharednow 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 whatusers 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
smime.p7s
Description: S/MIME cryptographic signature
