[ https://issues.apache.org/jira/browse/YARN-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014497#comment-15014497 ]
Sangjin Lee commented on YARN-4053: ----------------------------------- As mentioned above the generic version is good only if {{add()}} and {{compare()}} would operate only on return values of {{decodeValue()}}. I'm not sure if that's always a reliable assumption although it happens to be true right now. [~jrottinghuis]? Can we go back to non-generic version for the ValueConverter hierarchy? Sorry for going back and forth on this one! Just one more minor nit. In {{LongConverter}}, {{decodeValue()}} can simply return {{Bytes.toLong()}} without using {{Long.valueOf()}}. The same goes for {{add()}}. Autoboxing will take care of that for you. > Change the way metric values are stored in HBase Storage > -------------------------------------------------------- > > Key: YARN-4053 > URL: https://issues.apache.org/jira/browse/YARN-4053 > Project: Hadoop YARN > Issue Type: Sub-task > Components: timelineserver > Affects Versions: YARN-2928 > Reporter: Varun Saxena > Assignee: Varun Saxena > Labels: yarn-2928-1st-milestone > Attachments: YARN-4053-YARN-2928.01.patch, > YARN-4053-YARN-2928.02.patch, YARN-4053-feature-YARN-2928.03.patch, > YARN-4053-feature-YARN-2928.04.patch, YARN-4053-feature-YARN-2928.05.patch, > YARN-4053-feature-YARN-2928.06.patch > > > Currently HBase implementation uses GenericObjectMapper to convert and store > values in backend HBase storage. This converts everything into a string > representation(ASCII/UTF-8 encoded byte array). > While this is fine in most cases, it does not quite serve our use case for > metrics. > So we need to decide how are we going to encode and decode metric values and > store them in HBase. > -- This message was sent by Atlassian JIRA (v6.3.4#6332)