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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache