On 11/18/2014 11:53 AM, Pedro Ruivo wrote: > Hi Pierre, > > Thanks for the feedback. > > My comments are inline. > > Cheers, > Pedro > > On 11/17/2014 12:22 PM, Pierre Sutra wrote: >> Hello Pedro, >> >> I read your design page with interest, and formulated a few >> remarks/questions below. Despite I do not know in details the internals, >> I Hope that they might be useful. >> >> Cheers, >> Pierre >> >> - It is unclear to me how the protocol execute reads, in particular >> regarding causality. If a reader waits for a single replica to answer, >> in case every write requires all replicas to answer, this is fine. >> However, it seems that a writer can return as soon as a single replica >> returns an acknowledgement. In such a case, it might be the case that a >> reader do not see its own modifications, if it retrieves data from a >> replica that did not apply the modifications yet. > > You're right. The writer must wait for all the replies except if the > cache is full replicated (in this case, it can wait for the self-deliver). > >> >> - Do you ensure impotency of commands inside ISPN ? In my understanding, >> it is necessary when switching from a view v1 to a view v2, as commands >> delivered at the end of v1 might be already executed. > > I'm lost here. can you be clear? are you talking about JGroups view or > Infinispan cache topology? > > On the latter matters and it will delivered the cache topology changes > in total order. So, everybody receives the same order of events. > >> >> - I would call your replication protocol "virtual synchrony based" >> instead, as it is relying on the virtual synchrony abstraction provided >> by JGroups. > > I don't think so. If I recall correctly, virtual synchrony ensures that > if a message is sent in view *v* then it is delivered in view *v*.
Are you using virtual synchrony at all ? IIRC there's no FLUSH protocol in the default configs. TBH, I don't recommend this anyway. > First, that cases is not necessary since we retry the commands received > in different topologies. Second, the protocol relies on the order in > which the operations are delivered. > >> >> >> On 10. 11. 14 15:49, Pedro Ruivo wrote: >>> Hi, >>> >>> FYI, I've just created a design page: >>> https://github.com/infinispan/infinispan/wiki/Total-Order-non-Transactional-Cache >>> >>> My plan is to implement it in 7.1 release. >>> >>> Feel free to comment. >>> >>> Cheers, >>> Pedro >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban Lead JGroups / Clustering Team JBoss _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
