[infinispan-dev] Threadpools in a large cluster

[Bela Ban]

On 2/7/13 1:38 PM, Dan Berindei wrote:
>
>
>
>
>
>     No, I think it'll apply to all messages. A simple implementation could
>     dispatch OOB messages to the thread pool, as they don't need to be
>     ordered. Regular messages could be added to a queue where they are
>     processed sequentially by a *single* thread. Pedro does implement
>     ordering based on transactions (see his prev email), and I think there
>     are some other good use cases for regular messages. I think one thing
>     that could be done for regular messages is to implement something like
>     SCOPE (remember ?) for async RPCs: updates to different web sessions
>     could be processed concurrently, only updates to the *same* session
>     would have to be ordered.
>
>
> Yeah, I agree implementing the regular message ordering ourselves 
> would give us a little more room for optimizations. But it would make 
> our part more complicated, too. Well, not for Total Ordering, because 
> Pedro already implemented it, but for our regular async scenarios we'd 
> need to add a thread pool (we want to allow 2 threads from different 
> sources to access different keys at the same time).

We don't need to implement this *now*, but let's agree on the API 
(feedback from Pedro and you guys), and add this in JGroups 3.3.

You can start out with a very simple implementation, or no 
implementation at all (then you'd have the same behavior as now), but 
the point is that you can do this at your own pace, and don't depend on 
any changes in JGroups (once 3.3 is used by Infinispan).

I agree that optimization of thread/request processing *while still 
preserving ordering where needed* might be a bit tricky, but the 
potential benefits are great. You could for example add request 
priorities by adding a parameter/flag to RPCs and dispatching them to a 
priority queue in your thread pool, without me having to change anything.

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