On Oct 6, 2011, at 4:04 PM, Mircea Markus wrote:
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?
BaseStateTransferManagerImpl.ViewChangeListener? Dan seems to disagree. You meant
TransactionTable.StaleTransactionCleanup instead?
>
> 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