[
https://issues.apache.org/jira/browse/FLINK-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15948796#comment-15948796
]
Tzu-Li (Gordon) Tai commented on FLINK-4195:
--------------------------------------------
In https://github.com/apache/flink/pull/3651, where a few more config keys was
added for timestamp-based start position, I think the "messy" config problem
with the Kinesis consumer code was brought up again.
Generally, the problem is that we have eager config props validation and
parsing locally, but internally in the consumer code we also need to extract
the configuration from the props again, leading to a lot of duplicate code. The
suggestions in this JIRA here should solve the problem.
I don't think we need to change the user API for this. Just to have a
consolidated config object that takes the user-given `Properties`, and does all
the config parsing + validating in that class. The internals of the Kinesis
consumer just fetch configuration from that new config object.
FYI [~tonywei], in case you're interested in this one :)
> Dedicated Configuration classes for Kinesis Consumer / Producer
> ---------------------------------------------------------------
>
> Key: FLINK-4195
> URL: https://issues.apache.org/jira/browse/FLINK-4195
> Project: Flink
> Issue Type: Improvement
> Components: Kinesis Connector, Streaming Connectors
> Affects Versions: 1.1.0
> Reporter: Tzu-Li (Gordon) Tai
>
> While fixing FLINK-4170, I feel that configuration and default value setting
> & validation is quite messy and unconsolidated for the current state of the
> code, and will likely become worse as more configs grow for the Kinesis
> connector.
> I propose to have a dedicated configuration class (instead of only Java
> properties) along the lines of Flink's own {{Configuration}}, so that the
> usage pattern is alike. There will be separate configuration classes for
> {{FlinkKinesisConsumerConfig}} and {{FlinkKinesisProducerConfig}}.
> [~uce] [~rmetzger] What do you think? This will break the interface, so if
> we're to change this, I'd prefer to fix it along with FLINK-4170 for Flink
> 1.1.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
