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

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

    [ https://issues.apache.org/jira/browse/FLINK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16225051#comment-16225051 ] 

Aljoscha Krettek commented on FLINK-7947:
-----------------------------------------

+1 I think most code around {{ParemeterTool}} would benefit from a proper design and refactoring.

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