Re: IoFilter lifecycles

[peter royal]

On Mar 4, 2006, at 12:36 PM, [EMAIL PROTECTED] wrote:

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.

yup, but you can delegate the execution to a ThreadPoolExecutor while still preserving the ordering.

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

maximum performance therefore they will not be using 1.4 JVMs. Perhaps

sure it could be automated). This would enable use of some of the
concurrent data structures. For example, one thing we noticed was some

the contention was reduced.

classes. People who are writing network servers are often interested in 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 contention in ByteBuffer since access to the stacks were synchronized. I change this to use the ConcurrentLinkedQueue instead of the MINA Queue and

I whole-heartedly agree here.

-pete

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

smime.p7s
Description: S/MIME cryptographic signature