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

ASF GitHub Bot commented on FLINK-4018:
---------------------------------------

Github user tzulitai commented on a diff in the pull request:

    https://github.com/apache/flink/pull/2071#discussion_r70064126
  
    --- Diff: 
flink-streaming-connectors/flink-connector-kinesis/src/main/java/org/apache/flink/streaming/connectors/kinesis/internals/ShardConsumer.java
 ---
    @@ -155,6 +163,15 @@ public void run() {
                                        // we can close this consumer thread 
once we've reached the end of the subscribed shard
                                        break;
                                } else {
    +                                   if (fetchIntervalMillis != 0) {
    +                                           if (LOG.isDebugEnabled()) {
    +                                                   LOG.debug(
    +                                                           "Consumer {} of 
subtask {} is sleeping for {} milliseconds before fetching the next batch of 
records ...",
    --- End diff --
    
    Makes sense, I'll remove it!


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

Reply via email to