[ 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 (v6.3.4#6332)