[jbosscache-dev] Re: Non Blocking State Transfer Status (& Integration with JGroups)
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