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)