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

Bela Ban bela at jboss.com
Thu Jan 8 03:22:08 EST 2009



Jason T. Greene wrote:
>> 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 ;)

Right, but if you use streaming state transfer, it actually does use a 
TCP connection. Regular state transfer doesn't. Well, it uses whatever 
the transport uses, whereas streaming ST creates its own TCP conn no 
matter what


-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat



More information about the jbosscache-dev mailing list