[jbosscache-dev] Re: Non Blocking State Transfer Status (& Integration with JGroups)

[Jason T. Greene]

Bela Ban wrote:
> 
> 
> Jason T. Greene wrote:
>>
>>> Also, I may be wrong but I believe the UNICAST and NAKACK locks are 
>>> separate, so a thread carrying a unicast state transfer message from 
>>> node A will not block on recipient B because a multicast replication 
>>> message from A is being handled by another thread.)
>>>
>>
>> I am not too worried about the locking, although that is a factor, but 
>> more about a multicast configuration, where you have state transfer 
>> traffic for N transfers hitting the multicast address. Even if 
>> everyone discards the traffic, it still has to be processed in java 
>> land, and it will be alot of traffic.
> 
> Why the multicast address ? State transfer should be between 2 nodes, a 
> provider and a requester, so it should always be unicast. If we bring 
> partial flush into the mix, where we block only the 2 participants in 
> the state transfer, then we should be OK. Not sure if we should do a 
> partial or a full flush though...

Ah! There is my disconnect. I somehow had it in my head that the jgroups 
UDP transport used a multicast socket for everything, and that UNICAST 
packets where just emulated on top of that. I should have looked at the 
code. That pretty much eliminates my concern. Although IMO a bare tcp 
connection would still be the most optimal form of transferring large 
state to a single node since the kernel and the hardware is doing all 
the work. That can be saved for a future optimization though ;)

-- 
Jason T. Greene
JBoss, a division of Red Hat