[
https://issues.apache.org/jira/browse/HADOOP-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625783#action_12625783
]
Owen O'Malley commented on HADOOP-3970:
---------------------------------------
Let's just keep the display names. The internal names are for mostly for
mapping to the counters. Yes, in theory the display names could collide, but in
practice they won't, because they are always displayed to the user by the
display name.
I think that putting in the lengths would make it very hard to read. I think it
is better to stay with in the current scheme and use the current:
{code}
g1.c1: v1, g1.c2:v2, ...
{code}
As you point out, that means we need to quote the characters . : , and probably
" and \.
> 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
>
>
> 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.
