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

> 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,

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

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.