Re: [infinispan-dev] Why no use async listener executor?

On Oct 6, 2011, at 12:26 PM, Dan Berindei wrote: > I've been been > trying to reuse the async transport executor in my cache views > manager, but I didn't know it's also configured to use 1 thread max > and I spent a good part of yesterday trying to understand what's going > on :) > I eventually moved on to create my own executor because I also wanted > to name my threads better and I couldn't find a simple way to include > the node name in the async transport executor's thread names, but I'm > pretty sure 1 is not a reasonable default for the async transport > either. I think we should have a chat online to see what exactly you're trying to do and see if we can accomodate it. I'm looking into this area right now.

Btw, if you end up creating your executor, you need to follow the global configuration rules. I'd probably suggest that I commit first https://issues.jboss.org/browse/ISPN-1396 so that you can get an idea of how I extended other parts to use shared executors. Btw, async transport does not use 1 as default, but instead 25 threads, see KnownComponentNames.

> > Cheers > Dan > > > On Wed, Oct 5, 2011 at 6:53 PM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: >> Hey guys, >> >> Re: https://issues.jboss.org/browse/ISPN-1396 >> >> While looking into this, I've discovered that we have been creating executors in cache level components, where we're calling submit from @Listener implementations. >> >> For example, BaseStateTransferManagerImpl.ViewChangeListener submits a rehash task and TransactionTable.StaleTransactionCleanup submits a tasks to break locks. >> >> Did the people that wrote these listeners (Dan & Mircea respectively) consider defining listeners to be called asynchronously? i.e. @Listener(sync = false) >> >> Unless you have very strict requirements, the async listener executor should just work, and would lead to reuse of executors which results in lower consumption. >> >> The same applies to the singleton store executor btw. >> >> Surely, if we were to expand on to other use cases, async notification executor should have more than 1 max thread by default, otherwise we could easily hold up tasks. >> >> Cheers, >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev