hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Li Lu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3431) Sub resources of timeline entity needs to be passed to a separate endpoint.
Date Fri, 17 Apr 2015 00:03:42 GMT

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

Li Lu commented on YARN-3431:
-----------------------------

Hi [~zjshen], thanks for the work! I reviewed your v3 patch. 

A general comment about the idea, if I understand correctly: Now we're requiring subclasses
to decide a strategy to encapsulate extended information into fields of TimelineEntity. We
will use TimelineEntity as standard object type for web services and storage. This introduces
conversion problems for subclasses. We need to provide some logic to rebuild subclasses based
on their entity types. In this patch the rebuild process is implemented as TimelineCollectorWebService.processTimelineEntities.


I have some questions:
# My main problem is with the "{{prototype}}" field of TimelineEntity. Firstly, the name is
a little bit awkward to me. It gives me an illusion that a class has a prototype of exactly
the same type, which is a little bit weird to me. Secondly, since all extended information
will be stored in TimelineEntity, the only thing different between subclass instances will
be in their type fields. If so, do we still need to have a separate "prototype" section for
web services? Thirdly, I searched the whole patch and seems like the only place to write to
this prototype field is in the constructor of TimelineEntity, where it simply stores the incoming
entity's prototype. I'm a little bit confused on this field overall. 
# For {{HierarchicalTimelineEntity}}, seems like we're not adding any special tags when we
{{addIsRelatedToEntity()}} in {{setParent()}}. We're also requiring the keySet of isRelatedToEntities
only have one key. Are we prohibiting the users from using {{isRelatedToEntities}} in {{HierarchicalTimelineEntity}}
completely to avoid problems? 
# Now {{processTimelineEntities}} is called in {{TimelineCollectorWebService}}, in {{putEntities}}.
From a storage layer perspective, I'm not sure if we really need the subclass information.
We definitely need the logic of {{processTimelineEntities}} in the reader side, and maybe
in our timeline collector implementation. 
# There are two ".*" imports in this patch, one in TestTimelineServiceClientIntegration and
the other in TimelineCollectorWebService. Maybe we'd like to list them explicitly? 

> Sub resources of timeline entity needs to be passed to a separate endpoint.
> ---------------------------------------------------------------------------
>
>                 Key: YARN-3431
>                 URL: https://issues.apache.org/jira/browse/YARN-3431
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Zhijie Shen
>         Attachments: YARN-3431.1.patch, YARN-3431.2.patch, YARN-3431.3.patch
>
>
> We have TimelineEntity and some other entities as subclass that inherit from it. However,
we only have a single endpoint, which consume TimelineEntity rather than sub-classes and this
endpoint will check the incoming request body contains exactly TimelineEntity object. However,
the json data which is serialized from sub-class object seems not to be treated as an TimelineEntity
object, and won't be deserialized into the corresponding sub-class object which cause deserialization
failure as some discussions in YARN-3334 : https://issues.apache.org/jira/browse/YARN-3334?focusedCommentId=14391059&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14391059.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message