hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Saxena (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-6027) Support fromid(offset) filter for /flows API
Date Tue, 28 Feb 2017 07:04:45 GMT

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

Varun Saxena commented on YARN-6027:

bq. Any converter class that does both can implement both separate interfaces.
To be honest, this is what I meant when I first made the comment about separating this out
into an interface. But after seeing Rohith's patch thought that as all row key converters
will be requiring encoding/decoding string row key variant so let us go with what's in the
patch. However, your point about this being orthogonal to current key version. And this being
more about conversion to/from String makes sense to me. So let us go with 2 separate interfaces.

bq. In terms of separator characters, I am of a little different opinion from Varun's. IMO
it would be better if we could reuse the same separator character (Separator.QUALIFIERS) as
a constant (not a new constant with the same value). 
Actually, the current patch does not use Separator enum for from id conversion. It uses 2
constants. My comment was more about using these constants in tests.
However, I did think of reusing Separator enum. But how do we fit in the escape char? Move
ESCAPE char also to Separator enum? Probably can be done but then it will not be used at all
in Separator enum. Picking one from Separator enum and other from a constant I thought would
be weird.
Also, I thought we will be mixing it up because for FROM_ID we would want URL safe characters
as separator and escape characters because this will be carried in URL in eventually. Whereas
Separator class is primarily used for conversion fo HBase bytes. So if somebody wishes to
change separator in HBase row key, would he have to take care of this being URL safe character
as well? We can probably leave a comment but then it would be somewhat restrictive.
This was the thought process behind not suggesting reuse of Separator#QUALIFIERS. Your thoughts
on the same? 

> Support fromid(offset) filter for /flows API
> --------------------------------------------
>                 Key: YARN-6027
>                 URL: https://issues.apache.org/jira/browse/YARN-6027
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Rohith Sharma K S
>            Assignee: Rohith Sharma K S
>              Labels: yarn-5355-merge-blocker
>         Attachments: YARN-6027-YARN-5355.0001.patch, YARN-6027-YARN-5355.0002.patch,
YARN-6027-YARN-5355.0003.patch, YARN-6027-YARN-5355.0004.patch, YARN-6027-YARN-5355.0005.patch
> In YARN-5585 , fromId is supported for retrieving entities. We need similar filter for
flows/flowRun apps and flow run and flow as well. 
> Along with supporting fromId, this JIRA should also discuss following points
> * Should we throw an exception for entities/entity retrieval if duplicates found?
> * TimelieEntity :
> ** Should equals method also check for idPrefix?
> ** Does idPrefix is part of identifiers?

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message