[
https://issues.apache.org/jira/browse/YARN-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15452583#comment-15452583
]
Varun Saxena edited comment on YARN-5585 at 8/31/16 3:51 PM:
-------------------------------------------------------------
If the use case is only for apps then the row keys in application table are
stored in sorted manner (in descending order) within the scope of a flow / flow
run.
And we can easily support fromId alongwith limit to achieve some sort of
pagination here without any performance penalty.
However, the problem with this kind of an approach is that new apps keep on
getting added so result may not be latest. For instance, if there are 100 apps
app100-app1 in ATS and we show 10 apps on each page. Then, if we move to page 3
we will show apps from app80-app71 but it is possible that say 5 more apps get
added in the meantime i.e. we now have app105 to app1 in ATS.
Ideally page 3 should then show app85-app76. But I guess this would have
already been considered.
Entities in entity table though are not sorted because entity could be anything.
If we have a similar use case for containers, we can consider separating it out
to a different table and have special handling for it. But there should be a
use case for it.
was (Author: varun_saxena):
If the use case is only for apps then the row keys in application table are
stored in sorted manner (in descending order) within the scope of a flow / flow
run.
And we can easily support fromId alongwith limit to achieve some sort of
pagination here without any performance penalty.
However, the problem with this kind of an approach is that new apps keep on
getting added so result may not be latest. For instance, if there are 100 apps
app100-app1 in ATS and we show 10 apps on each page. Then, if we move to page 3
we will show apps from app80-app71 but it is possible that say 5 more apps get
added in the meantime i.e. we not have app105 to app1 in ATS.
Ideally page 3 should then show app85-app76.
Entities in entity table though are not sorted because entity could be anything.
If we have a similar use case for containers, we can consider separating it out
to a different table and have special handling for it. But there should be a
use case for it.
> [Atsv2] Add a new filter fromId in REST endpoints
> -------------------------------------------------
>
> Key: YARN-5585
> URL: https://issues.apache.org/jira/browse/YARN-5585
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelinereader
> Reporter: Rohith Sharma K S
> Assignee: Rohith Sharma K S
>
> TimelineReader REST API's provides lot of filters to retrieve the
> applications. Along with those, it would be good to add new filter i.e fromId
> so that entities can be retrieved after the fromId.
> Example : If applications are stored database, app-1 app-2 ... app-10.
> *getApps?limit=5* gives app-1 to app-10. But to retrieve next 5 apps, it is
> difficult.
> So proposal is to have fromId in the filter like
> *getApps?limit=5&&fromId=app-5* which gives list of apps from app-6 to
> app-10.
> This is very useful for pagination in web UI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
