[infinispan-dev] Testing a Hot Rod client app, with smart routing disabled?

[Sanne Grinovero]

On 19 September 2016 at 14:14, Gustavo Fernandes <gustavo at 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 <ttarrant at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> >
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev