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