hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys some randomness
Date Tue, 10 Feb 2009 22:49:59 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Chris Douglas reassigned HADOOP-5079:

    Assignee: Jonathan Ellis  (was: Chris Douglas)


* A resolved issue is assigned to the person who did the work, not the person responsible
for the next step. Since you attached the patch ultimately committed, the issue should be
assigned to you.
* Generally, we work 1 patch/issue, so reverting is simple and it's easy to audit work. Reverting
your original patch, regenerating a repaired patch (since the new patch assumes the prior
one has been committed), and re-committing this issue isn't a good use of anyone's time.

Please create a new issue describing the regression and attach the patch.

>  HashFunction inadvertently destroys some randomness
> ----------------------------------------------------
>                 Key: HADOOP-5079
>                 URL: https://issues.apache.org/jira/browse/HADOOP-5079
>             Project: Hadoop Core
>          Issue Type: Bug
>          Components: util
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>             Fix For: 0.20.0
>         Attachments: hadoop-core-hash-2.patch, hadoop-core-hash.patch
> HashFunction.hash restricts initval for the next hash to the [0, maxValue) range of the
hash indexes returned. This is suboptimal, particularly for larger nbHash and smaller maxValue.
 Rather we should first set initval, then restrict the range for the result assignment.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message