[
https://issues.apache.org/jira/browse/HADOOP-3937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622293#action_12622293
]
Matei Zaharia commented on HADOOP-3937:
---------------------------------------
If the history start time has to go, then the best thing to do is to ensure
that JobID's are globally unique rather than hoping that the (jobid, job name,
user) combination will be unique. First of all, are JobID's actually unique
right now? My impression was that they weren't - they include jobtracker start
time and job number, but two trackers could give the same JobID. However, if we
keep the machine name in there, then the (machine, jobid) combination could be
unique. If you want to make sure JobID's are unique however, just use a GUID
generator, such as
http://java.sun.com/j2se/1.5.0/docs/api/java/util/UUID.html#randomUUID().
> Job history may get disabled due to overly long job names
> ---------------------------------------------------------
>
> Key: HADOOP-3937
> URL: https://issues.apache.org/jira/browse/HADOOP-3937
> Project: Hadoop Core
> Issue Type: Bug
> Affects Versions: 0.17.0, 0.17.1, 0.18.0, 0.19.0
> Reporter: Matei Zaharia
> Attachments: HADOOP-3937.patch
>
>
> Since Hadoop 0.17, the job history logs include the job's name in the
> filename. However, this can lead to overly long filenames, because job names
> may be arbitrarily long. When a filename is too long for the underlying OS,
> file creation fails and the JobHistory class silently disables history from
> that point on. This can lead to days of lost history until somebody notices
> the error in the log.
> Proposed solution: Trim the job name to a reasonable length when selecting a
> filename for the history file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
