hadoop-yarn-issues mailing list archives

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

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

Sangjin Lee commented on YARN-6027:

To me {{RowKeyConverter}} is really an orthogonal conversion from the existing key conversion
and operates on the string representation. In that sense, I would slightly prefer if it is
not an extension of {{KeyConverter}}. Any converter class that does both can implement both
separate interfaces.

Also, perhaps we could find a better name for {{RowKeyConverter}}. The key thing is not so
much that it is dealing with a row key as opposed to other {{KeyConverter}} types aren't.
Most of {{KeyConverter}} implementations do deal with row keys after all. I think what separates
this interface is the fact that it deals with the string representation (to be suitable for
embedding it in URLs). Perhaps something like {{KeyConverterToString}} or some other name
that's explicit to its purpose would be good.

I am also not 100% sold on {{RowKey}}. Again, it is not really about them being a row key
type. Should we not introduce this interface (and even the converter interface for that matter)
for now until it becomes clear we need polymorphism on this?

In terms of method names, how about making them very explicit about dealing with strings?
I would be more comfortable with names such as {{encodeAsString()}}, {{decodeFromString()}},
{{getRowKeyAsString()}}, {{parseRowKeyFromString()}}, and so on.

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). It is not so easy to keep track of many
encoding schemes, and it would be hard to keep track of all encoding characters. If we can
reuse the same whenever possible, it would help understand and maintain this code. I can be
persuaded otherwise, but I wanted to state my current take for the record.

bq. utils classes are not expected to be subclassed. Right? They just encapsulate a bunch
of static methods and constants.

Agree. It can be both public and final.

> 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