Hi Emmanuel, So if I have tasks that access database and communicate to external systems it is good to have solution that I have described in the previous post?
Also I have found that some of external systems sometimes have timeouts in communication so this is an argument for own thread pool. Actually I can have separated thread pool for those system so timeouts will not impact rest of system so much which will be in case if I use ExecutorFilter. I guess. Thanks Zlaja On Mon, Jul 1, 2013 at 10:52 AM, Emmanuel Lécharny <[email protected]>wrote: > Le 7/1/13 10:30 AM, Zlatko Josic a écrit : > > Thanks > > > > I have this in my code: > > > > config.getFilterChain().addLast("executor", > > new ExecutorFilter(new ThreadPoolExecutor(50, 400, 5 * 60 + 100, > > TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>()))); > > > > Also, I have > > set acceptor.getDefaultConfig().setThreadModel(ThreadModel.MANUAL), > beside > > this executor I have another thread pool that actually executed tasks. I > > suppose that ExecutorFilter, the first one, is for Worker that > reads/writes > > messages in MINA? Is this an architecture you suggested? Is there any > > difrence if the second pool is not implemented as ExecutorFilter ? > > Adding an executor filter in your chain is just a way to get your > handler being processed by a different thread than the one processing > the reads and writes. This is critical if your handler is going to > consume a lot of CPU (or wait for some condiftion to be met, blocking > the thread at the same time). > > You can of course add another pool of executor in your handler, but tjis > would be a bit overkilling in this case. > > One option is to not add the executor filter, and manage your pool of > thread in your own executor. It's really up to you. > > Let say that the ExecultorFilter is a convenient addition... > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
