[
https://issues.apache.org/jira/browse/YARN-4178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804487#comment-14804487
]
Joep Rottinghuis commented on YARN-4178:
----------------------------------------
[~vrushalic] we certainly have to store the application_ part.
[~gtCarrera9] for sure this can be done separate. We should do this in one fell
swoop in a consistent manner across the board.
If we do store three parts separately, we should probably store the epoch
timestamp first, then the app counter part (integer/long) and then the
application_.
As far as I know it would be possible to imagine that the RM would hand out
app_id's differently for Spark, or Tez, or MR or whatever the app framework
asks for. I'd imagine that we then have something like
application_<rm-start-epoch>_0001, spark_<rm-start-epoch>_0002,
application_<rm-start-epoch>_0003, tex_<rm-start-epoch>_0004 etc. where the
number still increase for each subsequent app.
> [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
>
> 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)
