You are viewing a plain text version of this content. The canonical link for it is here.

Posted to issues@aurora.apache.org by "Bill Farner (JIRA)" <ji...@apache.org> on 2015/04/29 17:08:05 UTC

[jira] [Updated] (AURORA-541) Figure out a better way of dealing with TaskConfigs in client queries

     [ https://issues.apache.org/jira/browse/AURORA-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bill Farner updated AURORA-541:
-------------------------------
    Priority: Minor  (was: Major)

> Figure out a better way of dealing with TaskConfigs in client queries
> ---------------------------------------------------------------------
>
>                 Key: AURORA-541
>                 URL: https://issues.apache.org/jira/browse/AURORA-541
>             Project: Aurora
>          Issue Type: Story
>          Components: Client, Scheduler
>            Reporter: Maxim Khutornenko
>            Priority: Minor
>
> The current approach of returning TaskConfigs from getTasksStatus RPC is not ideal from perf standpoint. While ScheduledTask->AssignedTask instantiation carries a specific meaning for every instance, the TaskConfigs are all identical in majority of the cases and just riding alone slowing down the RPC by their often enormous size. This creates a fertile ground for workarounds like AURORA-539. 
> Consider a normalized way of dealing with TaskConfigs that would avoid unnecessary repetition. E.g.: detaching TaskConfigs from the AssignedTask and serving them over a dedicated "getTaskConfigs" RPC.



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