[
https://issues.apache.org/jira/browse/YARN-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rohith Sharma K S updated YARN-5585:
------------------------------------
Attachment: YARN-5585-YARN-5355.0004.patch
updated patch with following delta changes from previous patch with testing in
real cluster.
# There are 2 query params for entities i.e fromidprefix and fromid.
# new query params are stored as filters and is used in getResult method.
# Added java doc for REST API's and others.
# Changed comparator of TimelineEntity in a descending order of idPrefix
otherwise in the order of lexicographical order of entityId. Here, I have not
changed equals method. I think entity should be differentiated using idPrefix
also. I mean equals method also should check for idPrefix.
Regarding Varun's point, 2 cents from my side
# I think we are tightly coupling between API layer to back-end i.e
HBase-storage-only. As of now, lets leave considering storage layer!
# To the question, Should throw exception indicating to users that there are
duplicate entities found? I feel NO if TimelineEntity equals method uses
idPrefix, so that it will be clear that any entity with same type and same id,
but idPrefix are different then both entities are unequal. Lets display all
entities.
> [Atsv2] Reader side changes for entity prefix and support for pagination via
> additional filters
> -----------------------------------------------------------------------------------------------
>
> 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
> Priority: Critical
> Labels: yarn-5355-merge-blocker
> Attachments: 0001-YARN-5585.patch, YARN-5585-YARN-5355.0001.patch,
> YARN-5585-YARN-5355.0002.patch, YARN-5585-YARN-5355.0003.patch,
> YARN-5585-YARN-5355.0004.patch, YARN-5585-workaround.patch, YARN-5585.v0.patch
>
>
> 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.
> Current Behavior : Default limit is set to 100. If there are 1000 entities
> then REST call gives first/last 100 entities. How to retrieve next set of 100
> entities i.e 101 to 200 OR 900 to 801?
> Example : If applications are stored database, app-1 app-2 ... app-10.
> *getApps?limit=5* gives app-1 to app-5. But to retrieve next 5 apps, there is
> no way to achieve this.
> 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.
> Since ATS is targeting large number of entities storage, it is very common
> use case to get next set of entities using fromId rather than querying all
> the entites. 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
