On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <rvansa(a)redhat.com
<mailto:rvansa@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.
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