[infinispan-dev] Why no use async listener executor?

[Dan Berindei]

Galder, I didn't know about @Listener(sync = false), but a separate
executor makes sense for state transfer because I didn't want
concurrent state transfers and I could set it up to automatically
cancels any state transfer task that's waiting in the queue.

For the StaleTransactionCleanup I suppose we could use an async
listener but it would definitely need a bigger thread pool because the
user might have async listeners as well.


If only you'd have sent this email one day before, I've been been
trying to reuse the async transport executor in my cache views
manager, but I didn't know it's also configured to use 1 thread max
and I spent a good part of yesterday trying to understand what's going
on :)

I eventually moved on to create my own executor because I also wanted
to name my threads better and I couldn't find a simple way to include
the node name in the async transport executor's thread names, but I'm
pretty sure 1 is not a reasonable default for the async transport
either.

Cheers
Dan


On Wed, Oct 5, 2011 at 6:53 PM, Galder Zamarreño <galder at redhat.com> 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)
>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>