Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 36AF0200CF4 for ; Sun, 3 Sep 2017 23:05:13 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 33FD3163CEB; Sun, 3 Sep 2017 21:05:13 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 78EA6163CEC for ; Sun, 3 Sep 2017 23:05:12 +0200 (CEST) Received: (qmail 2200 invoked by uid 500); 3 Sep 2017 21:05:11 -0000 Mailing-List: contact jira-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@kafka.apache.org Delivered-To: mailing list jira@kafka.apache.org Received: (qmail 2189 invoked by uid 99); 3 Sep 2017 21:05:11 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Sep 2017 21:05:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0490A183004 for ; Sun, 3 Sep 2017 21:05:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id t3QFwpSVM88u for ; Sun, 3 Sep 2017 21:05:06 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id B912460EEB for ; Sun, 3 Sep 2017 21:05:05 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D41D6E0CA2 for ; Sun, 3 Sep 2017 21:05:03 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 11B0424157 for ; Sun, 3 Sep 2017 21:05:02 +0000 (UTC) Date: Sun, 3 Sep 2017 21:05:02 +0000 (UTC) From: "Richard Yu (JIRA)" To: jira@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (KAFKA-5828) Allow explicitly setting polling interval for Kafka connectors MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sun, 03 Sep 2017 21:05:13 -0000 [ https://issues.apache.org/jira/browse/KAFKA-5828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16151950#comment-16151950 ] Richard Yu edited comment on KAFKA-5828 at 9/3/17 9:05 PM: ----------------------------------------------------------- In the Fetcher class, there is the {code} fetchRecord(int maxRecords) {code} method. It is indirectly called from the {code} pollOnce(long timeout) {code} method in ConsumerConfigs. Using the above method, it should be relatively simple to set a higher bound. Also, the {code} poll(long timeout) {code} method calls {code} pollOnce(long timeout) {code}. Using the timeout parameter, the interval could also be set. was (Author: yohan123): In the Fetcher class, there is the {code} fetchRecord(int maxRecords) {code} method. It is indirectly called from the {code} pollOnce(long timeout) {code} method in ConsumerConfigs. Using the above method, it should be relatively simple to set a higher bound. Also, the {code} poll(long timeout) {code} method calls {code} pollOnce(long timeout) {code}. Using the timeout parameter, the interval could also be set. > Allow explicitly setting polling interval for Kafka connectors > -------------------------------------------------------------- > > Key: KAFKA-5828 > URL: https://issues.apache.org/jira/browse/KAFKA-5828 > Project: Kafka > Issue Type: Improvement > Components: KafkaConnect > Reporter: Behrang Saeedzadeh > > I have a Kafka cluster deployed in our internal data center and a Kafka Connect server deployed in AWS that gets data records from a topic on the Kafka cluster and writes them into a Kinesis stream. > We want to ensure that our Kafka connect server does not saturate the available bandwidth between our internal data center and AWS. > Using {{max.partition.fetch.bytes}} we can limit the upper bound of data that can be fetched in each poll call. If we can also configure the poll interval, then we can limit how much data is transferred per partition per second. -- This message was sent by Atlassian JIRA (v6.4.14#64029)