[
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)
