[infinispan-dev] Consistent hashes and Hot Rod

[Sanne Grinovero]

+1 nice idea, but we need to consider that this could be limiting for
certain use cases.

It's fine for when we control the hash function, but when the hash
function can not be trusted, or the hash code of keys is forged, we
might want to use a prime number of buckets; I don't think this
applies to us in practice?

On 29 August 2013 13:35, Manik Surtani <msurtani at redhat.com> wrote:
> The Hot Rod protocol current passes the size of the hash space used to clients, so that clients are able to create a consistent hash and perform smart routing.
>
> https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.0#HotRodProtocol-Version1.0-HashDistributionAwareClientTopologyChangeHeader
> https://docs.jboss.org/author/display/ISPN/Hot+Rod+Protocol+-+Version+1.2#HotRodProtocol-Version1.2-HashDistributionAwareClientTopologyChangeHeader
>
> However there are no rules as to what this hash space is, and this forces clients to use the remainder operation when performing modular arithmetic.  This has been proven to be inefficient [1] [2] [3], and can be greatly improved if we made a simple assumption that the hash space will always be a power of two.
>
> Perhaps something we can add in v1.3 of the protocol, so that clients talking to a server using Hot Rod 1.3 can make the assumption that the hash space is a power of 2?
>
> WDYT?
>
> - Manik
>
>
> [1] http://dhruba.name/2011/07/12/performance-pattern-modulo-and-powers-of-two/
> [2] http://scicomp.stackexchange.com/questions/187/why-is-division-so-much-more-complex-than-other-arithmetic-operations
> [3] http://disruptor.googlecode.com/files/Disruptor-1.0.pdf (Page 5, last paragraph)
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev