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 57C62200D2D for ; Fri, 27 Oct 2017 23:10:08 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5657B160BF4; Fri, 27 Oct 2017 21:10:08 +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 A4725160BF2 for ; Fri, 27 Oct 2017 23:10:07 +0200 (CEST) Received: (qmail 5308 invoked by uid 500); 27 Oct 2017 21:10:06 -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 5160 invoked by uid 99); 27 Oct 2017 21:10:06 -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; Fri, 27 Oct 2017 21:10:06 +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 BC9B1180807 for ; Fri, 27 Oct 2017 21:10:05 +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 YHMSuHtJSTF8 for ; Fri, 27 Oct 2017 21:10:03 +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 381F85F5B8 for ; Fri, 27 Oct 2017 21:10:03 +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 29228E2573 for ; Fri, 27 Oct 2017 21:10:02 +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 8611D212FE for ; Fri, 27 Oct 2017 21:10:01 +0000 (UTC) Date: Fri, 27 Oct 2017 21:10:01 +0000 (UTC) From: "Gaurav Nanda (JIRA)" To: jira@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (KAFKA-5505) Connect: Do not restart connector and existing tasks on task-set change MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 27 Oct 2017 21:10:08 -0000 [ https://issues.apache.org/jira/browse/KAFKA-5505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222835#comment-16222835 ] Gaurav Nanda commented on KAFKA-5505: ------------------------------------- We also have been facing this issue, we have a bunch of source connectors running on a connect cluster in production, everytime we create a new connector all the existing connectors are restarted for rebalancing. This disrupts the data loading process for some time, more then number of connectors and tasks, longer it takes for the process to get back up and running. We should be able to avoid restarting all existing connectors if a new one is added to the cluster. The only solution for us is to have a new cluster created dynamically when we need a new connector. Which is a clunky solution ... I have talked to some people in meetups and have found more people who are affected by this. I would really recommend fixing this. > Connect: Do not restart connector and existing tasks on task-set change > ----------------------------------------------------------------------- > > Key: KAFKA-5505 > URL: https://issues.apache.org/jira/browse/KAFKA-5505 > Project: Kafka > Issue Type: Improvement > Components: KafkaConnect > Affects Versions: 0.10.2.1 > Reporter: Per Steffensen > > I am writing a connector with a frequently changing task-set. It is really not working very well, because the connector and all existing tasks are restarted when the set of tasks changes. E.g. if the connector is running with 10 tasks, and an additional task is needed, the connector itself and all 10 existing tasks are restarted, just to make the 11th task run also. My tasks have a fairly heavy initialization, making it extra annoying. I would like to see a change, introducing a "mode", where only new/deleted tasks are started/stopped when notifying the system that the set of tasks changed (calling context.requestTaskReconfiguration() - or something similar). > Discussed this issue a little on dev@kafka.apache.org in the thread "Kafka Connect: To much restarting with a SourceConnector with dynamic set of tasks" -- This message was sent by Atlassian JIRA (v6.4.14#64029)