; although I was
mostly concerned on it allocating on a (very) hot path and didn't look
at it in terms of compatibility modes.
Rather than xorring with "magic numbers" don't you think we
Equivalence implementation should be able to rule on that?
On 23 November 2015 at 10:26, Radim Vansa <rvansa(a)redhat.com> wrote:
Hi guys,
I have noticed that even in library mode we use MurmurHash3 to find out
the segment for particular key. For strings, this involves encoding into
UTF-8 and computation of hashCode, instead of just reading the cached
value in string. Common objects just remix the bits of hashCode. When
user provides custom Equivalence with non-default hashCode, it is not
used to determine the segment.
I think that in library mode we should rather use Equivalence.hashCode,
maybe XORed with some magic number so that there are less collisions in
DataContainer.
If we simply replaced the function in CH, we would break the case when
user starts HR server on top of library mode, as the clients expect key
location based on MurmurHash3. ATM user only has to set
AnyServerEquivalence for keys in DC; we would need to detect
configuration with server equivalence and set CH function to MH3, and
probably also log some warning if the equivalence is set to unknown
class and CH function is not specified.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev