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

Reply via email to