On Nov 9, 2007 6:08 AM, Mike Heath <[EMAIL PROTECTED]> wrote:
> Impressive. +1 A 20% performance increase is amazing. Way to go!
I've just finished refactoring. :)
> I'm curious. What was causing the bottleneck with ExecutorFilter +
> Executors.newFixedThreadPool() that UnorderedExecutorFilter +
> OrderedThreadPoolExecutor overcomes? Did you find this bottleneck using
> a profiler?
Actually I didn't run any profiler because the introduction of
OrderedThreadPoolExecutor was to provide event throttling for those
who don't need such a complicated throttling that
org.apache.mina.filter.traffic provides. Performance improvement was
just an accident(?). :D
> After looking over OrderedThreadPoolExecutor, the only suggestion I have
> is to modify setMaximumPoolSize(int maximumPoolSize). Currently if the
> new maximumPoolSize is smaller then the actual maximumPoolSize, it
> invokes removeWorker() multiple times based on the difference.
> Shouldn't it really look something like:
>
> @Override
> public void setMaximumPoolSize(int maximumPoolSize) {
> synchronized (workers) {
> if (maximumPoolSize > corePoolSize) {
> setCorePoolSize(maximumPoolSize);
> }
> this.maximumPoolSize = maximumPoolSize;
> }
> }
>
> This way the corePoolSize field will get updated if need be and
> setCorePoolSize will update the the workers size if need be. I don't
> have much experience with the implementations of ThreadPoolExecutors so
> let me know if I'm off base.
corePoolSize is a configuration property that represent the minimum
size of the pool. So, I think updating corePoolSize property doesn't
make sense. Am I missing something?
Cheers,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
