[
https://issues.apache.org/jira/browse/PHOENIX-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225935#comment-14225935
]
Gabriel Reid commented on PHOENIX-1472:
---------------------------------------
[~jamestaylor] you're correct about it being quite unlikely, any given row has
a 1 in 4 billion chance of having this situation. Have we got a list of release
notes somewhere so that this can be added?
Your alternative solution is actually much better, because it remains backwards
compatible with the current implementation -- I just noticed that my patch
would break reading of any row keys with negative hash values.
> 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)
