[
https://issues.apache.org/jira/browse/PHOENIX-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabriel Reid updated PHOENIX-1472:
----------------------------------
Attachment: PHOENIX-1472.patch
Here is the trivial patch to resolve this issue.
The bigger issue is probably how to deal with backwards compatibility. My guess
is that the biggest problem that will be caused by this bug right now is that
range scans that cover a salted key with this condition won't include the
affected row in their results (and the affected row will appear in some range
scans where it doesn't belong). There are probably some other situations as
well. However, if this patch is applied it would mean that the affected old
row(s) would basically become invisible within Phoenix when using a new client.
It would be possible to migrate these rows as part of an upgrade process, but
that would then make the migrated rows invisible to new clients.
> SaltingUtil calculates wrong salt key for Integer.MIN_VALUE hash code
> ---------------------------------------------------------------------
>
> Key: PHOENIX-1472
> URL: https://issues.apache.org/jira/browse/PHOENIX-1472
> Project: Phoenix
> Issue Type: Bug
> Reporter: Gabriel Reid
> Attachments: PHOENIX-1472.patch
>
>
> There is an edge case in SaltingUtil.getSaltingByte where an invalid salt
> byte is calculated. This happens when the hash code of the row key being
> salted is equal to {{Integer.MIN_VALUE}}. The underlying bug is the use of
> Math.abs(hashCode) in SaltingUtil.getSaltingByte, and the result of the bug
> is that a hash code outside of the range of configured salt buckets can be
> returned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
