[
https://issues.apache.org/jira/browse/MAPREDUCE-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddharth Seth updated MAPREDUCE-2965:
--------------------------------------
Attachment: MR2965_v3.patch
Updated patch.
Re-using number format.
Updated allowed releaseaudit and findbugs warnings to 0
bq. Several needed null-checks are missing in toString() and comparesTo()
methods in all the IDs.
Have hesitantly added some null checks to toString() (not compareTo). I don't
think we should be adding these null checks for toString, hashCode and
comapreTo. They'll just end up masking actual errors. Are there any cases for
the ids to be used without all parameters set ?
bq. Thought more about this, and realized I am wrong about this. Because
getProto() itself is synchronized, and we only use the getters which are also
synchronized, we are good.
Yep, we should be fine - and without deadlocks like 2954.
> 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, MR2965_v3.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 implementation.
> 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
