[infinispan-issues] [JBoss JIRA] (ISPN-2801) Should ByteArrayKey handling in MurmurHash3 be moved to Hot Rod server?

[Galder Zamarreño (JIRA)]

Galder Zamarreño created ISPN-2801:
--------------------------------------

             Summary: Should ByteArrayKey handling in MurmurHash3 be moved to Hot Rod server?
                 Key: ISPN-2801
                 URL: https://issues.jboss.org/browse/ISPN-2801
             Project: Infinispan
          Issue Type: Task
            Reporter: Galder Zamarreño
            Assignee: Mircea Markus
            Priority: Minor
             Fix For: 5.3.0.Final


[12:19]  <manik> mmarkus: ok, next question.  This looks like a bug.
[12:19]  <manik> mmarkus: so on the client, we route requests based on the key, which is in the form of a byte[]
[12:19]  <manik> mmarkus: as per org.infinispan.client.hotrod.impl.consistenthash.ConsistentHash#getServer(byte[] key)
[12:20]  <mmarkus> manik: yes
[12:20]  <manik> mmarkus: and the key is serialised using whatever marshaller is configured on the client
[12:20]  <manik> but when that key arrives on the server
[12:20]  <manik> it is wrapped into a ByteArrayKey
[12:20]  <manik> and that is used on the server to map the entry to a node
[12:21]  * vchepeli (chepa653 at nat/redhat/x-svfcqlzqtfwwujho) has left #infinispan
[12:21]  * papegaaij has quit (Remote host closed the connection)
[12:21]  <manik> mmarkus: so potentially what the client sees as data owners and what the server nodes see as data owners are different?
[12:21]  <manik> galderz: you got a sec for this?  
[12:21]  <galderz> sure manik 
[12:21]  <manik> galderz: pls see my comments to mmarkus above
[12:23]  * sannegrinovero (Sanne at redhat/jboss/sannegrinovero) has joined #infinispan
[12:23]  * ChanServ gives voice to sannegrinovero
[12:23]  <galderz> manik, the hash on the ByteArrayKey is essentially a hash on the contens of the byte array
[12:24]  * tsykora (tsykora at nat/redhat/x-eelluveahnctzoui) has joined #infinispan
[12:24]  <galderz> to be precise: 41 + Arrays.hashCode(data)
[12:24]  <galderz> that the passed through the MurmurHash
[12:26]  <galderz> manik, we handle it:
[12:26]  <galderz>       else if (o instanceof ByteArrayKey)
[12:26]  <galderz>          return hash(((ByteArrayKey) o).getData());
[12:27]  <galderz> so manik, regardless of whether it's a byte[] or a ByteArrayKey, the hash should be the same, //cc mmarkus 
[12:28]  <mmarkus> galderz: +1
[12:28]  * mmarkus has quit (Quit: Leaving.)
[12:28]  <galderz> i'm quite certain we have some tests that verify this - can't remember of the top of my head
[12:28]  <manik> galderz: ah, yes this is in the murmurhash3 impl
[12:29]  <manik> ok, no wonder I couldnt find it
[12:29]  <manik> :)
[12:29]  <manik> I just saw that on one side you're calling locate() with a byte[] and on the other, with a ByteArrayKey so that set off an alarm
[12:30]  <galderz> manik, you have a point though, it shou;dn't be specific to MurmurHash3
[12:39]  <manik> galderz: do you want to create a JIRA to refactor this somewhere else?  E.g., it makes sense for this logic to actually be in the Hot Rod server code - since that's where ByteArrayKeys are used.  :)
[12:40]  <galderz> manik, why? clients still need this logic too
[12:40]  <manik> galderz: no they dont
[12:40]  <galderz> oh, u mean handling BAKs?
[12:40]  <manik> yep
[12:40]  <galderz> manik, maybe… but did u check the history to see why that was put there?
[12:41]  <manik> No - maybe worth a chat with dberindei?
[12:41]  <manik> galderz: ^^

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira