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