hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4025) Deal with byte representations of Longs in writer code
Date Mon, 10 Aug 2015 17:30:46 GMT

    [ https://issues.apache.org/jira/browse/YARN-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14680410#comment-14680410

Sangjin Lee commented on YARN-4025:

Went over the patch pretty quickly, and have some high level comments.

- now that YARN-3049 is in, you'd need to modify {{HBaseTimelineReaderImpl}} also to do the
right thing regarding the timestamps.
- I am making a similar change for refactoring the unit tests in YARN-3906. I'm also renaming
the methods to make it more explicit what the test is about (please see the latest patch for
YARN-3906). So depending on the order in which these changes go in, we need to reconcile this.
Just a heads up.
- Regarding changing the character for the separator, is it causing a real bug? Do we really
need to change it? Note that we want to update the table description javadoc too if we're
going to change it.

> Deal with byte representations of Longs in writer code
> ------------------------------------------------------
>                 Key: YARN-4025
>                 URL: https://issues.apache.org/jira/browse/YARN-4025
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Vrushali C
>            Assignee: Vrushali C
>         Attachments: YARN-4025-YARN-2928.001.patch
> Timestamps are being stored as Longs in hbase by the HBaseTimelineWriterImpl code. There
seem to be some places in the code where there are conversions between Long to byte[] to String
for easier argument passing between function calls. Then these values end up being converted
back to byte[] while storing in hbase. 
> It would be better to pass around byte[] or the Longs themselves  as applicable. 
> This may result in some api changes (store function) as well in adding a few more function
calls like getColumnQualifier which accepts a pre-encoded byte array. It will be in addition
to the existing api which accepts a String and the ColumnHelper to return a byte[] column
name instead of a String one. 
> Filing jira to track these changes.

This message was sent by Atlassian JIRA

View raw message