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] [Comment Edited] (YARN-6027) Support fromid(offset) filter for /flows API
Date Mon, 27 Feb 2017 17:51:45 GMT

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

Varun Saxena edited comment on YARN-6027 at 2/27/17 5:51 PM:
-------------------------------------------------------------

[~rohithsharma],
bq. both are same right? any issues will happen because of enum? I debug the code, the value
is ! itself in cluster. May be need to add more combination of tests.
They are both same right now. But what if somebody changes them in future? The variables/enums
used are different. FlowActivityRowKeyConverter#decode(byte[]) uses Separator#QUALIFIERS whereas
FlowActivityRowKeyConverter#decode(String) uses the constants defined in TimelineReaderUtils.
Same goes for encode methods.
If somebody in future changes either one of them i.e. changes QUALIFIERS but not  SEPARATOR_CHAR
to something other than "!", the intention of test case won't be served. So it would be better
to use the respective constant/enum as per the converter method being invoked. This was the
intention behind comment.
bq. IIUC, public static final constants need not to be annotated 
Sorry, my bad. We do use FROM_ID outside the scope of tests and TimelineReaderUtils.
bq. RowKeyConvertor interface extended from KeyConvertor interface. RowKey is interface which
is implemented by HBase table row key class . Both RowKeyConvertor and RowKey interfaces are
different.
What I meant was to define RowKeyConverter interface as under. We do not expect RowKeyConverter
to be extended for anything other than type parameter being subtype of RowKey. Right? As your
javadoc also says this interface has to be implemented *for encoding and decoding row keys
only*. Defining it like below would sort of enforce this condition if all row keys implement
RowKey interface.
{code}
public interface RowKeyConverter<R extends RowKey> extends KeyConverter<R>
{code}
bq. Even I got doubt while removing final, why it should be final? utils class should be public
utils classes are not expected to be subclassed. Right? They just encapsulate a bunch of static
methods and constants.


was (Author: varun_saxena):
[~rohithsharma],
bq. both are same right? any issues will happen because of enum? I debug the code, the value
is ! itself in cluster. May be need to add more combination of tests.
They are both same right now. But what if somebody changes them in future? The variables/enums
used are different. FlowActivityRowKeyConverter#decode(byte[]) uses Separator#QUALIFIERS whereas
FlowActivityRowKeyConverter#decode(String) uses the constants defined in TimelineReaderUtils.
Same goes for encode methods.
If somebody in future changes either one of them i.e. changes QUALIFIERS but not  SEPARATOR_CHAR
to something other than "!", the intention of test case won't be served. So it would be better
to use the respective constant/enum as per the converter method being invoked. This was the
intention behind comment.
bq. IIUC, public static final constants need not to be annotated 
Sorry, my bad. We do use FROM_ID outside the scope of tests and TimelineReaderUtils.
bq. RowKeyConvertor interface extended from KeyConvertor interface. RowKey is interface which
is implemented by HBase table row key class . Both RowKeyConvertor and RowKey interfaces are
different.
What I meant was to define RowKeyConverter interface as under. We do not expect RowKeyConverter
to be extended for anything other than type parameter being subtype of RowKey. Right? 
{code}
public interface RowKeyConverter<R extends RowKey> extends KeyConverter<R>
{code}
bq. Even I got doubt while removing final, why it should be final? utils class should be public
utils classes are not expected to be subclassed. Right? They just encapsulate a bunch of static
methods and constants.

> 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
(v6.3.15#6346)

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


Mime
View raw message