hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13382) IntegrationTestBigLinkedList should use SecureRandom
Date Sat, 04 Apr 2015 00:22:34 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395395#comment-14395395
] 

Hudson commented on HBASE-13382:
--------------------------------

FAILURE: Integrated in HBase-1.1 #357 (See [https://builds.apache.org/job/HBase-1.1/357/])
HBASE-13382 IntegrationTestBigLinkedList should use SecureRandom (Dima Spivak) (stack: rev
e3d6cdd072d153f3d23fc59e6326abf182353bb8)
* hbase-it/src/test/java/org/apache/hadoop/hbase/test/IntegrationTestBigLinkedList.java


> IntegrationTestBigLinkedList should use SecureRandom
> ----------------------------------------------------
>
>                 Key: HBASE-13382
>                 URL: https://issues.apache.org/jira/browse/HBASE-13382
>             Project: HBase
>          Issue Type: Bug
>          Components: integration tests
>            Reporter: Todd Lipcon
>            Assignee: Dima Spivak
>             Fix For: 2.0.0, 1.0.1, 1.1.0
>
>         Attachments: HBASE-13382_master_v1.patch
>
>
> IntegrationTestBigLinkedList currently uses java.util.Random to generate its random keys.
The keys are 128 bits long, but we generate them using Random.nextBytes(). The Random implementation
itself only has a 48-bit seed, so even though we have a very long key string, it doesn't have
anywhere near that amount of entropy.
> This means that after a few billion rows, it's quite likely to run into a collision:
 filling in a 16-byte key is equivalent to four calls to rand.nextInt(). So, for 10B rows,
we are cycling through 40B different 'seed' values. With a 48-bit seed, it's quite likely
we'll end up using the same seed twice, after which point any future rows generated by the
colliding mappers are going to be equal. This results in broken chains and a failed verification
job.
> The fix is simple -- we should use SecureRandom to generate the random keys, instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message