6:39 a.m.
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
7:52 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:14 a.m.
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.
[1] https://github.com/infinispan/infinispan/blob/master/core/sr
c/test/java/org/infinispan/distribution/MagicKey.java
On Mon, Sep 19, 2016 at 1:52 PM, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:23 a.m.
On 19 September 2016 at 14:14, Gustavo Fernandes <gustavo(a)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/o...
On Mon, Sep 19, 2016 at 1:52 PM, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:19 a.m.
On 19 September 2016 at 13:52, Tristan Tarrant <ttarrant(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
8:24 a.m.
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
<ttarrant(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
9:48 a.m.
Sanne,
this should work for you:
https://github.com/infinispan/infinispan/pull/4561
You're welcome :)
Tristan
On 19/09/16 15:24, Tristan Tarrant wrote:
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 <ttarrant(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
3504
days inactive
3506
days old
infinispan-dev@lists.jboss.org
6 comments
3 participants
participants (3)
-
Gustavo Fernandes -
Sanne Grinovero -
Tristan Tarrant