[
https://issues.apache.org/jira/browse/FLINK-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348168#comment-15348168
]
ASF GitHub Bot commented on FLINK-4018:
---------------------------------------
Github user rmetzger commented on a diff in the pull request:
https://github.com/apache/flink/pull/2071#discussion_r68386857
--- Diff:
flink-streaming-connectors/flink-connector-kinesis/src/main/java/org/apache/flink/streaming/connectors/kinesis/internals/ShardConsumerThread.java
---
@@ -105,6 +117,8 @@ public void run() {
break;
} else {
+ Thread.sleep(idleMillisBetweenFetches);
--- End diff --
I'm not sure if its a good idea to introduce this waiting time by default.
Imagine we are consuming slowly because downstream operations are
expensive. Then, we would introduce an artificial slowdown (in latency and
throughput). I would suggest to:
- Set the value by default to 0
- Only call sleep if the idle time is > 0.
> Configurable idle time between getRecords requests to Kinesis shards
> --------------------------------------------------------------------
>
> Key: FLINK-4018
> URL: https://issues.apache.org/jira/browse/FLINK-4018
> Project: Flink
> Issue Type: Sub-task
> Components: Kinesis Connector, Streaming Connectors
> Affects Versions: 1.1.0
> Reporter: Tzu-Li (Gordon) Tai
> Assignee: Tzu-Li (Gordon) Tai
> Fix For: 1.1.0
>
>
> Currently, the Kinesis consumer is calling getRecords() right after finishing
> previous calls. This results in easily reaching Amazon's limitation of 5 GET
> requests per shard per second. Although the code already has backoff & retry
> mechanism, this will affect other applications consuming from the same
> Kinesis stream.
> Along with this new configuration and the already existing
> `KinesisConfigConstants.CONFIG_SHARD_RECORDS_PER_GET`, users will have more
> control on the desired throughput behaviour for the Kinesis consumer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
