Btw, state transfer and lock break service's executors are based around the concept of having a single thread running for each of the executors and either discarding any other requests (i.e. view changes) while there's an executor in use.
So, how do these carry on functioning the same way when all caches share the same cache manager? You can't just have an executor of 1 because it could easily cause different caches to block each other. If you have a thread pool of N, you could easily find yourself in the situation where multiple threads execute rehashing for a single cache for example, which I don't think is desirable. A custom thread factory could make sure only as many different cache threads are created, but the problem is still there. If you have 5 caches and you create 5 threads, two consecutive view changes for a cache could still result in two paralell threads executing it. I can't think of an easy way to resolve this with the standard executors available and maintaining a central executor for all caches. This might be a situation where it does make sense having cache specific executor configuration. Besides, these executors are single thread ones, so even if you create thousands of caches, the cost should be relatively small. Thoughts? On Oct 7, 2011, at 9:05 AM, Galder Zamarreño wrote: > > On Oct 6, 2011, at 5:48 PM, Mircea Markus wrote: > >> >> 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 :-) > > Ok. I'll get this changed as part of ISPN-1396. > >> >> >> >> _______________________________________________ >> 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 -- 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
