[infinispan-dev] Let me understand DIST

[Bela Ban]

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)