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

Varun Saxena commented on YARN-4178:
------------------------------------

After giving some further thought over it, in the patch, I have not stored 
application_ in the row key and using ApplicationId for conversion.
The reason is same as above. ApplicationId class is used across YARN to 
represent app id. Any change in app id format would reflect in this class too.
If we do not use this class, we have to write our own custom conversion method 
and from maintenance point of view, any future changes in app id format may be 
missed here.
If we really want to store application_ part due to the example given by Joep, 
maybe we can add a method in ApplicationId which takes in prefix as an 
additional parameter instead of taking it from static field. 
Thoughts ?

Also, if we follow approach in the patch, conversion to ApplicationId from 
string can be done while filling the context itself. But as we need to refactor 
reader code and  have common context for reader and writer, we can do this 
later.

> [storage implementation] app id as string can cause incorrect ordering
> ----------------------------------------------------------------------
>
>                 Key: YARN-4178
>                 URL: https://issues.apache.org/jira/browse/YARN-4178
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>    Affects Versions: YARN-2928
>            Reporter: Sangjin Lee
>            Assignee: Varun Saxena
>         Attachments: YARN-4178-YARN-2928.01.patch
>
>
> Currently the app id is used in various places as part of row keys and in 
> column names. However, they are treated as strings for the most part. This 
> will cause a problem with ordering when the id portion of the app id rolls 
> over to the next digit.
> For example, "app_1234567890_100" will be considered *earlier* than 
> "app_1234567890_99". We should correct this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to