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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
