4:37 a.m.
On Wed, Dec 11, 2013 at 11:37 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
> Hi Dan
>
> I am not speaking about changing something for the C++ client, I
> understand that the client code cannot be changed in order to keep the
> backward compatibility.
>
Sure, I was just trying to give some background information on what we
discussed and why we still have the wheel-based CH in the client.
>
> The current hash-wheel approach is working well, but there are few flaws
> that could be fixed keeping the client code untouched. Please, correct me
> if I am wrong.
>
> 1) The denormalization is executed for every client for every topology
> change/client join. I don't have any numbers, but calling the hashing
> algorithm million times per every such occasion sounds as wasting computing
> power. -> cache the denormalized stuff on server
>
+1, like I said it would be easy to do but it never came up as a problem
before.
Fair enough.
>
> 2) The server is sending numOwners hashIds per segment, one for each
> owner. What's the reason for that? I think that only primary owners should
> be inserted there. This would:
>
The main reason is to support clients from Infinispan 5.1, which pick a
random owner instead of always choosing the primary (
https://issues.jboss.org/browse/ISPN-2655).
You can always report numKeyOwners=1 and the old code should handle that.
Yeah, it looks like it would work. I was thinking that when retrying a
failed operation, the pre-5.2 client would still try one of the key owners,
but I see now that it always chose a random server when retrying. Also, the
client doesn't expose numKeyOwners to the user, like I had assumed.
> a) target all PUT requests to primary owner, reducing PUT latency and
> lowering the general load in cluster
>
Nope, it wouldn't. The same fraction of requests would go to the primary
owner as before, because we won't find the exact "denormalized" hash id
that maps to the segment border when normalized.
Oh, only now have I noticed that the hashIds are sorted by the normalized
ID, therefore, the primary owner always picks the first position (and most
requests will hit the first). Mea culpa. Still, it makes no sense to
include the backup owners into the routing table, as the probability that a
read will hit them is negligable.
b) reduce the routing information
>
For 7.0, I guess we could say that 5.1 clients are no longer supported
and we could switch to sending only the primary owners to the clients. But
I'm not sure whether the loss of backwards compatibility is worth a couple
hundred bytes sent once for every client.
> And yes, ISPN-3530 and ISPN-3701 are pretty serious, but IMO rather
> orthogonal to the segment vs. hash wheel approach and its details.
>
>
Agree. Could you create issues in JIRA for both your proposals?
OK. By the way, shouldn't we tag the features that should be included for
hotrod protocol v1.4 with some tag, such as hotrod14?
But as I said, if we fake the numOwners to be always 1, it should be
backwards compatible even now.
Nevertheless, as you in fact do route most requests to the primary owner,
it won't provide much performance gain and it's not as hot as I first
thought.
Radim
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev