Re: [infinispan-dev] JGroups 2.7 and 2.8 work with Infinispan now

Manik Surtani wrote: We have to differentiate: regardless of the presence of FLUSH, a *unicast* message is completely independent from multicast messages and views. In your scenario, however, this is likely a multicast (unless you have buddy replication enabled, or use DIST). Without FLUSH, C may or may not receive the put(x,y). With FLUSH, 2 scenarios are possible: 1. A,B,C receive the view V2, then the put() 2. A,B receive the put(), then A,B,C receive the view V2. In this case, C does NOT receive the put() because it logically joined after the put() Yes, if FLUSH is not present. No, that should *not* occur because messages will always be received by C even though it is still blocked. The blocking only affects the *sending* of messages. Second, C will have view {A,B,C} installed, or else it would not receive the unblock(). Therefore, any messages from A or B would NOT get dropped. Third, even if that was the case (it isn't), any dropped message from A or B would get retransmitted when A or B sends the next message to C, or before the next view gets installed. Again, only with FLUSH though ! I don't think this is a good solution b/c it essentially does what virtual synchrony (FLUSH) does -- Bela Ban Lead JGroups / Clustering Team JBoss - a division of Red Hat