]
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@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@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@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: