I don't know if the backport implementation can be better than native implementation of ThreadPool in Java 5. My feeling would be that the native implementation should be better, but only benchmark can say that...
I saw also a blocking queue implemented in MINA using synchronized. If I look at several papers on the concurrent part of Java 5, they all say that BlockingQueue from concurrent is better than using synchronized (far better). However the blocking queue in Mina is quite specific, so perhaps changing it to Java 5 model can be difficult. Thank you Peter for your help ! For the backport jar, can we imagine a way to extract this dependency since if I recall well from the mailing list, it was introduced also to allow to use native or specific implementation of the Thread Pool. And keeping the dependency even if we don't use it, it is quite strange, isn't it ? For the moment I try to make my own executor package using the same name than backport in order to not have bad dependency without this jar, but it is not really pretty... :-( Any idea ? Frederic On Sat, 2006-09-23 at 09:32 -0700, peter royal wrote: > On Sep 23, 2006, at 2:38 AM, Frédéric Brégier wrote: > > Do I need to re-code ExecutorThreadModel and any > > files that match the backport jar ? > > Or do I need to do something more simple as specifying > > somewhere my own thread pool ? > > > > And last question, does Mina now depend en backport > > or can I still use it without this jar ? > > You still need the backport jar, as well as the java5 module for mina. > > do something like: > > IoConfig.setThreadModel( ThreadModel.MANUAL ); > IoConfig.getFilterChain().addFirst( new ExecutorFilter( new > ExecutorExecutor( Executors.newCachedThreadPool() ) ) ); Hi guys What are the benefits/pitfalls of using the Java5 concurrent stuff compared to the MINA implementation? Ta. -- Frederic Soulier <[EMAIL PROTECTED]> OpenPGP key available on http://www.keyserver.net 1024D/BA6700ED 49A6 8E8E 4230 8D41 1ADE B649 3203 1DD2 BA67 00ED
