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

[Galder Zamarreño (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galder Zamarreño resolved ISPN-2801.
------------------------------------

    Fix Version/s:     (was: 5.3.0.Final)
       Resolution: Rejected


ByteArrayKey is no longer used by none of the servers. It's still used by some cache loader logic.
                
> 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: Galder Zamarreño
>            Priority: Minor
>
> [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