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] [Updated] (YARN-4025) Deal with byte representations of Longs in writer code
Date Tue, 18 Aug 2015 20:56:46 GMT

     [ 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)

Mime
View raw message