<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 11:37 AM, Radim Vansa <span dir="ltr"><<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Dec 11, 2013 at 10:38 AM,
Radim Vansa <span dir="ltr"><<a href="mailto:rvansa@redhat.com" target="_blank">rvansa@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Dan<br>
<br>
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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
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.<br>
<br>
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<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>+1, like I said it would be easy to do but it never
came up as a problem before.<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></div>
Fair enough.<div class="im"><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
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:<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The main reason is to support clients from Infinispan
5.1, which pick a random owner instead of always choosing
the primary (<a href="https://issues.jboss.org/browse/ISPN-2655" target="_blank">https://issues.jboss.org/browse/ISPN-2655</a>).<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
You can always report numKeyOwners=1 and the old code should handle
that.</div></blockquote><div><br></div><div>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.<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>
<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> a) target all PUT requests to primary owner,
reducing PUT latency and lowering the general load in
cluster<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> b) reduce the routing information<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
And yes, ISPN-3530 and ISPN-3701 are pretty serious,
but IMO rather orthogonal to the segment vs. hash
wheel approach and its details.<span><font color="#888888"><br>
<br>
</font></span></div>
</div>
</blockquote>
<div><br>
</div>
<div>Agree. Could you create issues in JIRA for both your
proposals? <br>
</div>
</div>
</div>
</div>
</blockquote>
<br></div>
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?<br>
But as I said, if we fake the numOwners to be always 1, it should be
backwards compatible even now.<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Radim<br>
<br>
</font></span></div>
<br>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></div><br></div></div>