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