#1 I would by default have 1 thread pool shared by all caches #2 This global thread pool should be configurable, perhaps in the <global> section ? #3 Each cache by default uses the gobal thread pool #4 A cache can define its own thread pool, then it would use this one and not the global thread pool
I think this gives you a mixture between ease of use and flexibility in configuring pool per cache if needed On 06/11/14 16:23, Pedro Ruivo wrote: > > > On 11/06/2014 03:01 PM, Bela Ban wrote: >> >> >> On 06/11/14 15:36, Pedro Ruivo wrote: >>> >>> * added a single thread remote executor service. This will handle the >>> FIFO deliver commands. Previously, they were handled by JGroups incoming >>> threads and with a new executor service, each cache can process their >>> own FIFO commands concurrently. >> >> +1000. This allows multiple updates from the same sender but to >> different caches to be executed in parallel, and will speed thing up. >> >> Do you intend to share a thread pool between the invocations handlers of >> the various caches, or do they each have their own thread pool ? Or is >> this configurable ? >> > > That is question that cross my mind and I don't have any idea what would > be the best. So, for now, I will leave the thread pool shared between > the handlers. > > Never thought to make it configurable, but maybe that is the best > option. And maybe, it should be possible to have different max-thread > size per cache. For example: > > * all caches using this remote executor will share the same instance > <remote-executor name="shared" shared="true" max-threads=4.../> > > * all caches using this remote executor will create their own thread > pool with max-threads equals to 1 > <remote-executor name="low-throughput-cache" shared="false" > max-threads=1 .../> > > * all caches using this remote executor will create their own thread > pool with max-threads equals to 1000 > <remote executor name="high-throughput-cache" shared="false" > max-thread=1000 .../> > > is this what you have in mind? comments? > > Cheers, > Pedro > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev