[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