That means users adding their own counters and wanting to avoid the
cumbersome names would need to copy the default properties file and
add their own to it, but they would then have full control over all
the displayed names.
Many users prefer to know as little as possible about system entities.
Copying a system properties file by a user would require the user to
keep updating her copy as the system adds or modifies its counters. A
small nightmare.
Consolidation is good, semantically related counters would be better
put into a single enum. But unrelated ones should not share.
On Feb 26, 2007, at 12:15 PM, David Bowen (JIRA) wrote:
[
https://issues.apache.org/jira/browse/HADOOP-1041?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel#action_12475984 ]
David Bowen commented on HADOOP-1041:
-------------------------------------
I was assuming we would have a single ResourceBundle (properties file)
for the counter names, because it is good to have one place that you
can go and configure everything that appears in the counter table that
you see on the web page. That means users adding their own counters
and wanting to avoid the cumbersome names would need to copy the
default properties file and add their own to it, but they would then
have full control over all the displayed names.
Still, I see some benefits in the suggestion of multiple
ResourceBundles. Currently there are several different counter enum
classes in the map-reduce framework, but it doesn't need to be that
way. We could have just one enum class for "system" counters.
Allowing for multiple properties per counter is an interesting twist,
although it is possibly getting a bit close to the over-engineering
that James warned against.
Grouping the counters by their enumeration class seems like an
excellent idea.
Counter names are ugly
----------------------
Key: HADOOP-1041
URL: https://issues.apache.org/jira/browse/HADOOP-1041
Project: Hadoop
Issue Type: Improvement
Components: mapred
Affects Versions: 0.12.0
Reporter: Owen O'Malley
Fix For: 0.12.0
Having the complete class name in the counter names makes them
unique, but they are ugly to present to non-developers. It would be
nice to have some way to have a nicer string presented to the user.
Currently, the Enum is converted to a name like:
key.getDeclaringClass().getName() + "#" + key.toString()
which gives counter names like
"org.apache.hadoop.examples.RandomWriter$Counters#BYTES_WRITTEN"
which is unique, but not very user friendly. Perhaps, we should strip
off the class name for presenting to the users, which would allow
them to make nice names. In particular, you could define an enum type
that overloaded toString to print a nice user friendly string.
Thoughts?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
