[JBoss JIRA] Created: (ISPN-809) CassandraCacheLoader not working with HotRod server due to non deterministic toString() in ByteArrayKey
3:30 a.m.
CassandraCacheLoader not working with HotRod server due to non deterministic toString() in
ByteArrayKey
-------------------------------------------------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Manik Surtani
Priority: Critical
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:50 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Manik Surtani updated ISPN-809:
-------------------------------
Summary: CassandraCacheStore needs special handling of array type keys (was:
CassandraCacheLoader not working with HotRod server due to non deterministic toString() in
ByteArrayKey)
Fix Version/s: 4.2.0.CR3
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Manik Surtani
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:50 a.m.
New subject: [JBoss JIRA] Assigned: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Tristan Tarrant reassigned ISPN-809:
------------------------------------
Assignee: Tristan Tarrant (was: Manik Surtani)
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:58 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Jonas Lasson commented on ISPN-809:
-----------------------------------
Ideally it would be good to get an extendable way of determining identities for different
types of objects instead of just defaulting to .toString() (which works excellently for
string based keys).
I'd suggest creating an interface like ICassandraIdentityProvider { String
getIdentityKey( Object o ) } which would return null if it did not know how to produce an
identity.
Then configure the cache store with a list of classnames that implements the above
interface which will consulted in order until a provider returns a non null value. If all
returns null, do toString.
Config:
<property name="identityProviders"
value="com.awesome.CompanySpecificKeyProviders,com.awesome.ThirdPartyKeyProviders"
/>
Alternative /MEFA-INF/services/ lookup.
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Tristan Tarrant commented on ISPN-809:
--------------------------------------
Yes, I like that. I'll see what I can do for CR3.
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:06 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Jonas Lasson commented on ISPN-809:
-----------------------------------
Awesomes :) If you'd need inspirational advice, I'm on larry2kk skype.
I do need this issue to be fixed as I'm running on my own patch right now.
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:08 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Manik Surtani commented on ISPN-809:
------------------------------------
You could use Key2StringMapper - which is in the JDBCCacheStore. Perhaps we'd need to
move this interface and the impls in the JDBCCacheStore to the core module so it can be
shared across all cache stores.
https://github.com/infinispan/infinispan/blob/master/cachestore/jdbc/src/...
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:20 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Jonas Lasson commented on ISPN-809:
-----------------------------------
Manik,
This is exactly what I'm thinking of. Perhaps we should move that interface down from
jdbc to loaders, and make implementators configurable in a generic manner for any string
based key store :)
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:11 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Galder Zamarreño commented on ISPN-809:
---------------------------------------
One thing worth noting here is that printing the hashcode is actually an optional thing. I
can't remember whether why I made ByteArrayKey.toString() print the hashcode but most
likely is due to debugging. At first glance I don't see the need to print the
hashcode, but it's true as well depending on the output of ByteArrayKey.toString() is
dangerous, cos if you really wanted to get full information and be able to differentiate
between diff keys, you'd need to print the full byte array which might be several
kb/mb/gb.
As agreed here, a separation between String and non String keys might be necessary to
provide the right solution.
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:23 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Tristan Tarrant commented on ISPN-809:
--------------------------------------
I have implemented this on my Infinispan fork.
Can you have a look here ?
https://github.com/tristantarrant/infinispan/commit/a7c4a282efe0271a1dd53...
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:35 a.m.
New subject: [JBoss JIRA] Resolved: (ISPN-809) CassandraCacheStore needs special handling of array type keys
[
https://jira.jboss.org/browse/ISPN-809?page=com.atlassian.jira.plugin.sys...
]
Tristan Tarrant resolved ISPN-809.
----------------------------------
Resolution: Done
Resolved on my Infinispan fork, pull request issued for both master and 4.2.x
CassandraCacheStore needs special handling of array type keys
-------------------------------------------------------------
Key: ISPN-809
URL: https://jira.jboss.org/browse/ISPN-809
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 4.2.0.CR2
Reporter: Jonas Lasson
Assignee: Tristan Tarrant
Priority: Critical
Fix For: 4.2.0.CR3
Currently the Cassandra store is creating CassandraKeys based on the keys .toString
method, see below:
private String hashKey(Object key) {
return entryKeyPrefix + key.toString();
}
When HotRod server is used the key will be a ByteArrayKey, which has a toString that is
non deterministic and outputs (3 examples with the same byte array):
ByteArrayKey{data=ByteArray{size=8, hashCode=33d626a4, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=2ada52a1, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
ByteArrayKey{data=ByteArray{size=8, hashCode=5576b9ea, array=[2, 62, 5, 74, 79, 78, 65,
83, ..]}}
As you can see the hashCode is differing even though the byte array is the same.
This is because ByteArrayKey.toString is using Util.printArray(byte[],true) where true
means that a hashCode should be printed as well.
Unfortenaly, the hashcode is calculated with byte[].hashCode() which is not considering
the data in the byte array.
There are several solutions to the problem:
* Have another mechanism to export unique ids from the key instead of toString (with a
possible toString fallback)
* Fix so that ByteArrayKey.toString returns deterministic data. (Still bad solution as
the keys will be very long and not make sense).
* Special handling for ByteArrayKey to calculate the key based on the bytes in the byte
array.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4895
days inactive
4896
days old
infinispan-issues@lists.jboss.org
10 comments
4 participants
participants (4)
-
Galder Zamarreño (JIRA) -
Jonas Lasson (JIRA)
-
Manik Surtani (JIRA)
-
Tristan Tarrant (JIRA)