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

[Bela Ban]

Brian Stansberry wrote:
>> Thinking again, building this over JGroups would probably better with 
>> two static channels. One would be TCP + MPING, the other whatever the 
>> user defines.
>>
>
> I don't understand why two channels are needed. You can easily unicast 
> over the regular JGroups channel. Is your concern that the state 
> transfer messages between the sender and the recipient will get held 
> up by FC or UNICAST or something due to the regular traffic? I don't 
> see why that would be a big problem. The recipient until it completes 
> the state transfer isn't going to be doing anything (e.g. holding 
> locks) that will cause significant delays in processing state transfer 
> messages.  (Also, I may be wrong but I believe the UNICAST and NAKACK 
> locks are separate,

correct

> 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.)

yep

> Also, going back to your very first paragraph "flush and
> partial flush can not be used for this, since the application
> needs the ability to send state (tx log) during the flush" -- I 
> believe unicast messages are not blocked by FLUSH. Although depending 
> on that seems like a hack.

No, this is *guaranteed* by virtual synchrony which does *not* handle 
unicast messages

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