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 78941200D31 for ; Sat, 21 Oct 2017 00:56:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 7723F160BED; Fri, 20 Oct 2017 22:56:07 +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 C430D160BCB for ; Sat, 21 Oct 2017 00:56:06 +0200 (CEST) Received: (qmail 58930 invoked by uid 500); 20 Oct 2017 22:56: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 58917 invoked by uid 99); 20 Oct 2017 22:56:05 -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, 20 Oct 2017 22:56:05 +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 47D2B1807D7 for ; Fri, 20 Oct 2017 22:56:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id hklIrgluTqQ6 for ; Fri, 20 Oct 2017 22:56:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id DD7BE60DDA for ; Fri, 20 Oct 2017 22:56:02 +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 A47A3E256C for ; Fri, 20 Oct 2017 22:56:01 +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 596BB2439B for ; Fri, 20 Oct 2017 22:56:00 +0000 (UTC) Date: Fri, 20 Oct 2017 22:56:00 +0000 (UTC) From: "Ted Yu (JIRA)" To: jira@kafka.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (KAFKA-6101) Reconnecting to broker does not exponentially backoff MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 20 Oct 2017 22:56:07 -0000 [ https://issues.apache.org/jira/browse/KAFKA-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated KAFKA-6101: -------------------------- Attachment: (was: 6101.v1.txt) > Reconnecting to broker does not exponentially backoff > ----------------------------------------------------- > > Key: KAFKA-6101 > URL: https://issues.apache.org/jira/browse/KAFKA-6101 > Project: Kafka > Issue Type: Bug > Components: clients > Affects Versions: 0.11.0.0 > Reporter: Sean Rohead > Attachments: 6101.v2.txt, text.html > > > I am using com.typesafe.akka:akka-stream-kafka:0.17 which relies on kafka-clients:0.11.0.0. > I have set the reconnect.backoff.max.ms property to 60000. > When I start the application without kafka running, I see a flood of the following log message: > [warn] o.a.k.c.NetworkClient - Connection to node -1 could not be established. Broker may not be available. > The log messages occur several times a second and the frequency of these messages does not decrease over time as would be expected if exponential backoff was working properly. > I set a breakpoint in the debugger in ClusterConnectionStates:188 and noticed that every time this breakpoint is hit, nodeState.failedAttempts is always 0. This is why the delay does not increase exponentially. It also appears that every time the breakpoint is hit, it is on a different instance, so even though the number of failedAttempts is incremented, we never get the breakpoint for the same instance more than one time. -- This message was sent by Atlassian JIRA (v6.4.14#64029)