On 3/14/12 1:14 AM, Manik Surtani wrote: > > On 13 Mar 2012, at 03:28, Bela Ban wrote: > >> >> >> On 3/13/12 6:35 AM, Manik Surtani wrote: >>> >>> On 12 Mar 2012, at 08:03, Dan Berindei wrote: >>> >>>>> >>>>> Well, probably not, because we only want to send keys to nodes that >>>>> actually need to store them... >>>>> >>>> >>>> Sending the whole tx as a multicast would certainly be more efficient >>>> than what we do now with lots of targets. >>>> With unicasts we could send only the minimum required data to each >>>> target, but that computation would be complex and error-prone. >>> >>> Well, this is what ANYCAST was all about initially, where JGroups would >>> decide, based on the recipient list versus the total cluster size, on >>> whether to send multiple unicasts or a multicast. But we didn't end up >>> doing this in the end, perhaps we need to revisit. >>> >>> Bela, I'm guessing this thread was prompted by the poor performance in DIST >>> that was reported, right? I'd like to profile the test provided to >>> understand where we should be looking in the first place. E.g., is it the >>> fact that we have too many RPCs? Or maybe a locking/concurrency issue >>> elsewhere, etc. If you have done any of this analysis already, we should >>> talk about that. >> >> >> Yes. My current findings are that we're doing unneeded sync RPCs even if >> <async.../> is defined. I'll run this with the latest Infinispan and see >> if it's still the case (Galder mentioned this was gone in 5.2 master). >> Also, there should be performance improvements by locking only the >> primary owners (changes by Mircea and/or Dan), so I'll need to re-run >> with the latest and greatest of Infinispan (and JGroups). > > Any such changes should also be in 5.1.x. If you do see any sync RPCs > (except perhaps remote GETs) when running in async mode, then that is almost > certainly a bug.
Yes, this is a bug, I confirmed that with Dan yesterday. He's aware of it and the fix is simple, so I expect this will be fixed shortly. The workaround is to define <stateTransfer .../>. -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
