On 5 Oct 2011, at 16:53, Galder Zamarreño 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) this can work indeed for BaseStateTransferManagerImpl.ViewChangeListener? This seems like a small change - can you modify that in the scope of ISPN-1396 or do you want me to look into it? > > 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
