hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinod Kumar Vavilapalli (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-2965) Streamline hashCode(), equals(), compareTo() and toString() for all IDs
Date Wed, 14 Sep 2011 06:58:09 GMT

    [ https://issues.apache.org/jira/browse/MAPREDUCE-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104306#comment-13104306

Vinod Kumar Vavilapalli commented on MAPREDUCE-2965:

The patch looks fine overall. Some comments:
 - We can reuse the NumberFormat definitions for various IDs, no need to repeat them in each
 - Several needed null-checks are missing in {{toString()}} and {{comparesTo()}} methods in
all the IDs.
 - Looks like after your adding the licenses to the two tests, the allowed rat-warnings can
be set to zero in dev-support/test-patch.properties.

It just occurred to me that the way we are doing the {{hashCode()}}, {{equals()}} and {{comparesTo()}},
we are not synchronizing them as we like to avoid issues like MAPREDUCE-2954. But at the same,
I did find that each of those IDs can have some fields set to zero when a thread calls {{getProto}}
on them and the builder is still in progress. This seems to indicate that we will have very
unreliable {{hashCode()}}, {{equals()}} etc.

> Streamline hashCode(), equals(), compareTo() and toString() for all IDs
> -----------------------------------------------------------------------
>                 Key: MAPREDUCE-2965
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-2965
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mrv2
>    Affects Versions: 0.23.0, 0.24.0
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Siddharth Seth
>             Fix For: 0.23.0, 0.24.0
>         Attachments: MR2965_v1.patch, MR2965_v2.patch
> MAPREDUCE-2954 moved these methods to the record interfaces from the PB impls for ContainerId,
ApplicationId and ApplicationAttemptId. This is good as they don't need to be tied to the
> We should do the same for all IDs. In fact some of these are missing for IDs like MR
AM JobId, TaskId etc.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message