On Thu, Oct 6, 2011 at 5:51 PM, Galder Zamarreño <gal...@redhat.com> wrote: > > 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. >
Definitely, let's talk tomorrow. Maybe you'll be able to convince me of the usefulness of exposing all these configuration settings, up until now I haven't seen it used to fix things but I've seen at least one wrong configuration break things (by enabling queueing in the JGroups executors). > 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. > Hmm, maybe the test suite overrides it then? If I run a test and put a breakpoint in RpcManagerImpl.java:106 I see the injected executor has core size 1 and max size also 1. >> >> 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 > > -- > 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