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

On Oct 6, 2011, at 12:26 PM, Dan Berindei wrote: > 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. I think we should have a chat online to see what exactly you're trying to do and see if we can accomodate it. I'm looking into this area right now.

Btw, if you end up creating your executor, you need to follow the global configuration rules. I'd probably suggest that I commit first https://issues.jboss.org/browse/ISPN-1396 so that you can get an idea of how I extended other parts to use shared executors. Btw, async transport does not use 1 as default, but instead 25 threads, see KnownComponentNames.

> > Cheers > Dan > > > On Wed, Oct 5, 2011 at 6:53 PM, Galder Zamarreño <galder(a)redhat.com&gt; 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(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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

On 6 Oct 2011, at 15:52, Galder Zamarreño wrote: > > 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? yes indeed :-)

_______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

>>> >>>> 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? > yes indeed :-) Ok. I'll get this changed as part of ISPN-1396.