[infinispan-dev] Ideas for Hot Rod protocol improvements to support new hashing routing table

Hey Dan, Re: https://issues.jboss.org/browse/ISPN-2205 Sorry we couldn't have a proper chat but we can carry on via email. Extending to Infinispan Dev. | > [11:03] <dberindei> this is what I had in mind for the hotrod update: https://gist.github.com/3664504 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 https://gist.github.com/3664504 looks fine. 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. Do we still need hash space? I think we can assume this is fixed now to be all positive integers. | > [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 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. | > [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 | > [11:08] <dberindei> maybe we could specify in the protocol a different serialization for each function version? | > [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 | > [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 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. Cheers, -- Galder Zamarreño galder(a)redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org