[
https://issues.apache.org/jira/browse/HADOOP-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amar Kamat updated HADOOP-3970:
-------------------------------
Attachment: HADOOP-3970-v4.patch
Attaching a patch the incorporates Hemanth's comments.
bq. I think the escapeString(String str, char escapeChar, char charToEscape)
API is still useful by itself, and is easier to use in cases where the user has
only one char to escape. So, do we really need to deprecate this ?
The reason for deprecating the api is that I have introduced a new/enhanced api
that essentially does the same thing but is more generic. I personally dont
have any strong opinion about this.
> Counters written to the job history cannot be recovered back
> ------------------------------------------------------------
>
> Key: HADOOP-3970
> URL: https://issues.apache.org/jira/browse/HADOOP-3970
> Project: Hadoop Core
> Issue Type: Bug
> Components: mapred
> Reporter: Amar Kamat
> Attachments: HADOOP-3970-v1.patch, HADOOP-3970-v2.patch,
> HADOOP-3970-v3.patch, HADOOP-3970-v4.patch
>
>
> Counters that are written to the JobHistory are stringified using
> {{Counters.makeCompactString()}}. The format in which this api converts the
> counter into a string is _groupname.countername:value_. The problem is that
> _groupname_ and _countername_ can contain a '.' and hence recovering the
> counter becomes difficult. Since JobHistory can be used for various purposes,
> reconstructing the counter object back might be useful. One such usecase is
> HADOOP-3245. There should be some way to recover the counter object back from
> its string representation and also to keep the string version readable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
