[infinispan-dev] Denormalizing hashes

[Radim Vansa]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131211/9c5ef3c0/attachment.html