Yes, it means the client is not topology aware either. Tristan
On 19/09/16 15:19, Sanne Grinovero wrote: > On 19 September 2016 at 13:52, 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 ! > I'd also need the client to not "autodiscover" the nodes I didn't > explicitly list. > Would setting a "1" in this intelligence header be enough for that? > > Thanks! > Sanne > > >> 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