On Mar 13, 2012, at 8:28 AM, 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).
Hmmm, are you refering to the chat we had yesterday? We discused something else, related to replicated caches. Let me explain it for the rest of the audience: In the 4.x days, IIRC, to support non-blocking state transfer right, even if the cache was configured with repl async, the RPCs would be sent sync. So, the moment you enable state transfer, a repl async cache became repl sync. The thing is that this code is still present but state transfer has changed in 5.1 and I wondered if this was still needed. @Dan, thoughts? > 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). > > > -- > Bela Ban, JGroups lead (http://www.jgroups.org) > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
