[ https://issues.apache.org/jira/browse/YARN-4025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sangjin Lee updated YARN-4025: ------------------------------ Attachment: YARN-4025-YARN-2928.004.patch v.4 patch posted. - implemented proper handling of a null column prefix - added more javadoc to clarify several places - renamed the test from {{TestHBaseTimelineWriterImpl}} to {{TestHBaseTimelineStorage}} - clarified and made explicit the no-limit split - fixed javadoc comments for the value separator - added some logging statements This should address most of the review comments. I stopped short of renaming the {{readResults()}} method. We can treat that method as the "default" {{readResults()}} method, and the other one as the one for having raw (non-string) components. I added more javadoc to clarify that point. Let me know. > 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: Sangjin Lee > Attachments: YARN-4025-YARN-2928.001.patch, > YARN-4025-YARN-2928.002.patch, YARN-4025-YARN-2928.003.patch, > YARN-4025-YARN-2928.004.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)