On 3/4/06, peter royal <[EMAIL PROTECTED]> 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
