[infinispan-dev] Remoting package refactor

Bela Ban bban at redhat.com
Fri Nov 7 02:35:37 EST 2014


That's exactly what I suggested. No config gives you a shared global 
thread pool for all caches.

Those caches which need a separate pool can do that via configuration 
(and of course also programmatically)

On 06/11/14 20:31, Tristan Tarrant wrote:
> My opinion is that we should aim for less configuration, i.e.
> threadpools should mostly have sensible defaults and be shared by
> default unless there are extremely good reasons for not doing so.
>
> Tristan
>
> On 06/11/14 19:40, Radim Vansa wrote:
>> I second the opinion that any threadpools should be shared by default.
>> There are users who have hundreds or thousands of caches and having
>> separate threadpool for each of them could easily drain resources. And
>> sharing resources is the purpose of threadpools, right?
>>
>> Radim
>>
>> On 11/06/2014 04:37 PM, Bela Ban wrote:
>>> #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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


More information about the infinispan-dev mailing list