On 30 Aug 2013, at 14:13, Dan Berindei wrote:
> We will still have a division in the consistent hash, because the "number of
> segments" in some ways replaces . We just didn't add it to the HotRod
> protocol yet...
>
> I have thought about replacing division, and I was considering 2 options:
We will still have a division in the consistent hash, because the "number
of segments" in some ways replaces . We just didn't add it to the HotRod
protocol yet...
I have thought about replacing division, and I was considering 2 options:
1. Hide the power of 2 restriction in the consistent hash imp
Have you done a prototype and tested it to see if it improves performance?
"Inefficient" is a relative term. The difference in .3 billionths of a
second and .6 billionths of a second (rough numbers from a quick test)
is huge percentage wise, but only makes a difference in a tight loop
around th
Pls ignore. I've just been informed that hash space is to be dropped from the
protocol anyway.
On 29 Aug 2013, at 13:35, Manik Surtani 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
>
+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
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-HashDistributionAwareClientTopolog
