#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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Bela Ban, JGroups lead (
http://www.jgroups.org)