Zhijie Shen commented on YARN-2302:

Thanks for the input, Junping! Patch updated again.

bq. Shall we rename this method to putEntities?

This is a good question. AFAIK, PUT is used to update the entire resource and 
supposed to be idempotent. Therefore, I'm not sure it's an idea to change the 
method to PUT because once the entity is created, the following updates are 
actually appending more data to the existing one. The best fit should be PATCH, 
however, it requires the additional implementation at the web services side. 
Hence, somebody online suggested using POST for partial non-idempotent update 
as well. Anyway, i think it's not a simple code refactoring, I'll file another 
ticket to track the investigation of proper HTTP method for postEntities.

bq. In addition, I think we should have javadoc for public methods in 

As TimelineDataManager is not the user-oriented interface, I added some simple 
javadoc for the public methods, and link them to TimelineStoreReader for 
argument details.

> Refactor TimelineWebServices
> ----------------------------
>                 Key: YARN-2302
>                 URL: https://issues.apache.org/jira/browse/YARN-2302
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Zhijie Shen
>            Assignee: Zhijie Shen
>         Attachments: YARN-2302.1.patch, YARN-2302.2.patch, YARN-2302.3.patch
> Now TimelineWebServices contains non-trivial logic to process the HTTP 
> requests, manipulate the data, check the access, and interact with the 
> timeline store.
> I propose the move the data-oriented logic to a middle layer (so called 
> TimelineDataManager), and TimelineWebServices only processes the requests, 
> and call TimelineDataManager to complete the remaining tasks.
> By doing this, we make the generic history module reuse TimelineDataManager 
> internally (YARN-2033), invoking the putting/getting methods directly. 
> Otherwise, we have to send the HTTP requests to TimelineWebServices to query 
> the generic history data, which is not an efficient way.

This message was sent by Atlassian JIRA

Reply via email to