You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2009/01/19 22:48:59 UTC
[jira] Created: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
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
Attachments: 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated HADOOP-5079:
-----------------------------------
Attachment: hadoop-core-hash-2.patch
My first patch contained a regression: you have to take the remainder _before_ calling Math.abs, since Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE still.
> 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: stack
> 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.
[jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Chris Douglas (JIRA)" <ji...@apache.org>.
[ 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)
Jonathan-
* 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666841#action_12666841 ]
Hadoop QA commented on HADOOP-5079:
-----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12398264/hadoop-core-hash.patch
against trunk revision 737253.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no tests are needed for this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 Eclipse classpath. The patch retains Eclipse classpath integrity.
+1 core tests. The patch passed core unit tests.
-1 contrib tests. The patch failed contrib unit tests.
Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3756/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3756/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3756/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3756/console
This message is automatically generated.
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "Raghu Angadi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667903#action_12667903 ]
Raghu Angadi commented on HADOOP-5079:
--------------------------------------
The change log should be only in place : under 0.20 on trunk as well on 0.20 branch.
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665247#action_12665247 ]
stack commented on HADOOP-5079:
-------------------------------
Patch looks good to me. Will commit in a day or so unless objection.
> 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
> Attachments: 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated HADOOP-5079:
-----------------------------------
Attachment: hadoop-core-hash.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
> Attachments: 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated HADOOP-5079:
-----------------------------------
Hadoop Flags: (was: [Reviewed])
Status: Patch Available (was: Reopened)
> 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: stack
> 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.
[jira] Reopened: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reopened HADOOP-5079:
------------------------------------
> 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: stack
> 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.
[jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned HADOOP-5079:
--------------------------------------
Assignee: Chris Douglas (was: Jonathan Ellis)
Chris, I've reported the problem and attached a patch; I leave it to you to proceed from there as you see best. :)
> 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: Chris Douglas
> 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12666850#action_12666850 ]
stack commented on HADOOP-5079:
-------------------------------
Committed to 0.20 branch too.
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668095#action_12668095 ]
stack commented on HADOOP-5079:
-------------------------------
Thanks Raghu. I moved the CHANGES.txt entry.
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-5079:
--------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Committed (One line change that improves a random function -- hard to write unit tests for). Thanks for the patch Jonathan.
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673951#action_12673951 ]
Hudson commented on HADOOP-5079:
--------------------------------
Integrated in Hadoop-trunk #756 (See [http://hudson.zones.apache.org/hudson/job/Hadoop-trunk/756/])
> 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-5079:
--------------------------
Status: In Progress (was: Patch Available)
> 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
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-5079:
--------------------------
Fix Version/s: 0.20.0
Hadoop Flags: [Reviewed]
> 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
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674006#action_12674006 ]
stack commented on HADOOP-5079:
-------------------------------
I moved the patch that was added to the reopened issue to HADOOP-5255.
> 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.
[jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack reassigned HADOOP-5079:
-----------------------------
Assignee: stack
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Assigned: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Chris Douglas (JIRA)" <ji...@apache.org>.
[ 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: stack)
> 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Chris Douglas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Douglas updated HADOOP-5079:
----------------------------------
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
Jonathan: please open a new issue to correct the regression.
> 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: stack
> 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672157#action_12672157 ]
stack commented on HADOOP-5079:
-------------------------------
I took a look at the patch and confirmed Math.abs(Integer.MIN_VALUE is negative.
> 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "stack (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
stack updated HADOOP-5079:
--------------------------
Status: Patch Available (was: In Progress)
> 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: stack
> Fix For: 0.20.0
>
> Attachments: 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.
[jira] Commented: (HADOOP-5079) HashFunction inadvertently
destroys some randomness
Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669175#action_12669175 ]
Hadoop QA commented on HADOOP-5079:
-----------------------------------
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12399055/hadoop-core-hash-2.patch
against trunk revision 739416.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified tests.
Please justify why no tests are needed for this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 Eclipse classpath. The patch retains Eclipse classpath integrity.
+1 release audit. The applied patch does not increase the total number of release audit warnings.
+1 core tests. The patch passed core unit tests.
-1 contrib tests. The patch failed contrib unit tests.
Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3779/testReport/
Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3779/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Checkstyle results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3779/artifact/trunk/build/test/checkstyle-errors.html
Console output: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3779/console
This message is automatically generated.
> 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: stack
> 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.
[jira] Updated: (HADOOP-5079) HashFunction inadvertently destroys
some randomness
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HADOOP-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated HADOOP-5079:
-----------------------------------
Status: Patch Available (was: Open)
> 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
> Attachments: 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.