[infinispan-dev] Denormalizing hashes

[Dan Berindei]

On Wed, Dec 11, 2013 at 11:37 AM, Radim Vansa <rvansa at redhat.com> wrote:

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

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20131211/d79fb7e8/attachment.html