You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Bowen Li (JIRA)" <ji...@apache.org> on 2017/10/30 23:39:00 UTC

[jira] [Assigned] (FLINK-7947) Let ParameterTool return a dedicated GlobalJobParameters object

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

Bowen Li reassigned FLINK-7947:
-------------------------------

    Assignee: Bowen Li

> Let ParameterTool return a dedicated GlobalJobParameters object
> ---------------------------------------------------------------
>
>                 Key: FLINK-7947
>                 URL: https://issues.apache.org/jira/browse/FLINK-7947
>             Project: Flink
>          Issue Type: Improvement
>          Components: Client
>    Affects Versions: 1.4.0
>            Reporter: Till Rohrmann
>            Assignee: Bowen Li
>
> The {{ParameterTool}} directly implements the {{GlobalJobParameters}} interface. Additionally it has grown over time to not only store the configuration parameters but also to record which parameters have been requested and what default value was set. This information is irrelevant on the server side when setting a {{GlobalJobParameters}} object via {{ExecutionConfig#setGlobalJobParameters}}.
> Since we don't separate the {{ParameterTool}} logic and the actual data view, users ran into problems when reusing the same {{ParameterTool}} to start multiple jobs concurrently (see FLINK-7943). I think it would be a much clearer separation of concerns if we would actually split the {{GlobalJobParameters}} from the {{ParameterTool}}.
> Furthermore, we should think about whether {{ParameterTool#get}} should have side effects or not as it does right now.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)