Fair enough.
On Wed, Dec 11, 2013 at 10:38 AM, Radim Vansa <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.
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).
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.
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?