<div class="gmail_quote">On Fri, Sep 7, 2012 at 1:09 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hey Dan,<br>
<br>
Re: <a href="https://issues.jboss.org/browse/ISPN-2205" target="_blank">https://issues.jboss.org/browse/ISPN-2205</a><br>
<br>
Sorry we couldn't have a proper chat but we can carry on via email. Extending to Infinispan Dev.<br>
<br>
| > [11:03] <dberindei> this is what I had in mind for the hotrod update: <a href="https://gist.github.com/3664504" target="_blank">https://gist.github.com/3664504</a><br>
<br>
What is "1st owner's index"? Is that the position in the array of servers in topology above? I guess os, if so, I think <a href="https://gist.github.com/3664504" target="_blank">https://gist.github.com/3664504</a> looks fine.<br>
<br></blockquote><div><br>Yes, it's the position in the array of members.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's assuming the clients provide the normalized hash for the key (which they already do today), they should have all the info to locate in.<br>
<br>
Do we still need hash space? I think we can assume this is fixed now to be all positive integers.<br>
<br></blockquote><div><br>I figured I'd keep the new protocol a superset of 1.1, since the new CH format is quite generic it could theoretically used for any CH.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
| > [11:04] <dberindei> but thinking about it some more, I think it might be a good idea to talk about having a CH per cache on the client as well<br>
<br>
Supporting a CH per cache would not require any changes to the protocol, since all operations are per-cache, it would just need the client to cache the info accordingly.<br>
<br></blockquote><div><br>I think we might need some logic on the server as well, but you're probably right that the protocol doesn't need changes.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
| > [11:07] <dberindei> something else that came to mind: we allow the server to specify a hash function version, but the serialization of the CH is fixed based only on the client's version<br>
| > [11:08] <dberindei> maybe we could specify in the protocol a different serialization for each function version?<br>
| > [11:09] <dberindei> that way we could have a single client that can support any server CH via a very generic client CH like the new DCH<br>
| > [11:10] <dberindei> and at the same time, if the server knows that the client supports a fancier CH, it can send the other CH instead<br>
<br>
The Hash Function is there to define what 'hash function' the client uses. Whether that's MurmurHash3, MurmurHash2…etc. The serialization, or how we transmit the rest of hashing information should really be part of the protocol itself. I don't think we should change this.<br>
<br></blockquote><div><br>I think there's a slight confusion in the protocol/client here, the field is called 'hash function' but the client actually uses it to choose a ConsistentHash implementation (either ConsistentHashV1 or ConsistentHashV2). You're right that the only difference between the two is the actual hash function though.<br>
<br>I was thinking of using this as a sort of negotiation protocol: the client says it supports a protocol version, and the server picks one of the consistent hashes that it knows and is compatible with the client. But perhaps this would be better implemented as a proper negotiation, with the client specifying a range of supported protocol versions and the server replying with a single common version.<br>
<br>Cheers<br>Dan<br><br></div></div>