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