Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Date: Tue, 4 Nov 2014 15:39:34 +0000 (UTC)
From: "R. Tyler Croy (JIRA)" <jira@apache.org>
To: dev@kafka.apache.org
Message-ID: <JIRA.12750836.1414433511000.409340.1415115574109@Atlassian.JIRA>
In-Reply-To: <JIRA.12750836.1414433511000@Atlassian.JIRA>
References: <JIRA.12750836.1414433511000@Atlassian.JIRA>
 <JIRA.12750836.1414433511308@arcas>
Subject: [jira] [Commented] (KAFKA-1733) Producer.send will block
 indeterminately when broker is unavailable.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

R. Tyler Croy commented on KAFKA-1733:
--------------------------------------

Thanks a lot [~junrao]! As somebody not terribly familiar with the Kafka release process, is there a document you could point me to that describes the release cadence or when we might expect a release to be cut with this change?

> Producer.send will block indeterminately when broker is unavailable.
> --------------------------------------------------------------------
>
>                 Key: KAFKA-1733
>                 URL: https://issues.apache.org/jira/browse/KAFKA-1733
>             Project: Kafka
>          Issue Type: Bug
>          Components: core, producer 
>            Reporter: Marc Chung
>            Assignee: Marc Chung
>             Fix For: 0.8.3
>
>         Attachments: kafka-1733-add-connectTimeoutMs.patch
>
>
> This is a follow up to the conversation here:
> https://mail-archives.apache.org/mod_mbox/kafka-dev/201409.mbox/%3CCAOG_4QYMoEJHKbo0N31+A-UjX0z5unSiSD5WbrmN-XtX7giP-Q@mail.gmail.com%3E
> During ClientUtils.fetchTopicMetadata, if the broker is unavailable, socket.connect will block indeterminately. Any retry policy (message.send.max.retries) further increases the time spent waiting for the socket to connect.
> The root fix is to add a connection timeout value to the BlockingChannel's socket configuration, like so:
> {noformat}
> -channel.socket.connect(new InetSocketAddress(host, port))
> +channel.socket.connect(new InetSocketAddress(host, port), connectTimeoutMs)
> {noformat}
> The simplest thing to do here would be to have a constant, default value that would be applied to every socket configuration. 
> Is that acceptable? 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)