hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13382) IntegrationTestBigLinkedList should use SecureRandom
Date Fri, 03 Apr 2015 20:45:54 GMT

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

Hadoop QA commented on HBASE-13382:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12709283/HBASE-13382_master_v1.patch
  against master branch at commit d8b10656d00779e194c3caca118995136babce99.
  ATTACHMENT ID: 12709283

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 4 new or modified
tests.

    {color:green}+1 hadoop versions{color}. The patch compiles with all supported hadoop versions
(2.4.1 2.5.2 2.6.0)

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:green}+1 protoc{color}.  The applied patch does not increase the total number of
protoc compiler warnings.

    {color:green}+1 javadoc{color}.  The javadoc tool did not generate any warning messages.

    {color:green}+1 checkstyle{color}.  The applied patch does not increase the total number
of checkstyle errors

    {color:green}+1 findbugs{color}.  The patch does not introduce any  new Findbugs (version
2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number
of release audit warnings.

    {color:green}+1 lineLengths{color}.  The patch does not introduce lines longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

     {color:red}-1 core zombie tests{color}.  There are 2 zombie test(s): 	at org.apache.camel.component.jetty.jettyproducer.HttpJettyProducerRecipientListCustomThreadPoolTest.testRecipientList(HttpJettyProducerRecipientListCustomThreadPoolTest.java:40)
	at org.apache.camel.test.junit4.CamelTestSupport.startCamelContext(CamelTestSupport.java:477)
	at org.apache.camel.test.junit4.CamelTestSupport.doSetUp(CamelTestSupport.java:311)
	at org.apache.camel.test.junit4.CamelTestSupport.setUp(CamelTestSupport.java:217)

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/13556//testReport/
Release Findbugs (version 2.0.3) 	warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/13556//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/13556//artifact/patchprocess/checkstyle-aggregate.html

  Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/13556//console

This message is automatically generated.

> 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
>         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