On 19 September 2016 at 14:14, Gustavo Fernandes <gust...@infinispan.org> wrote: > You can try to generate keys that hash to specific servers and use them. > From the Hot Rod client you can > get .getCacheTopologyInfo that gives you the segment ownership for the > servers in the cluster, and to target > a specific server you'd craft a key that maps to a specific segment owned by > that server. I'd imagine the > implementation to be similar to [1] but for client-server mode.
In my case all writes happen on the same key: I want to verify my understanding of the versioning semantics is good enough to resolve conflicting writes on the same key, even though each client might physically connect to a different owner because of the topology being dynamic or network issues. > > [1] > https://github.com/infinispan/infinispan/blob/master/core/src/test/java/org/infinispan/distribution/MagicKey.java > > > On Mon, Sep 19, 2016 at 1:52 PM, Tristan Tarrant <ttarr...@redhat.com> > wrote: >> >> Currently thee Java client always sets the client intelligence header to >> 3 (topo + ch aware). We could add a configuration property so that you >> could specify 1 (basic). >> The alternative requires playing with the transport and playing with the >> "failed servers" but that is messy ! >> >> Tristan >> >> On 19/09/16 13:39, Sanne Grinovero wrote: >> > Hi all, >> > >> > I'm testing a concurrent update protocol based on Hot Rod client's >> > support for versioned entries. >> > >> > I would love to be able to write a test having multiple client >> > endpoints, each connecting to a specific server. Of course HR's "smart >> > routing" prevents me from controlling this explicitly.. is there a way >> > to control it? >> > >> > For example having servers {A, B} connected in cluster I'd like to >> > create two clients {A', B}', each one connected exclusively to one of >> > them and not aware of the other server node. (A <-> A', B <-> B'). >> > >> > Thanks, >> > Sanne >> > _______________________________________________ >> > infinispan-dev mailing list >> > infinispan-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev