[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582565#comment-15582565
]
Dru Panchal commented on KAFKA-1733:
As seen in the following file: The fix was made for the 0.9.0 release and it
was also back-ported into 0.8.2
https://github.com/apache/kafka/blob/0.9.0/core/src/main/scala/kafka/network/BlockingChannel.scala
https://github.com/apache/kafka/blob/0.8.2/core/src/main/scala/kafka/network/BlockingChannel.scala
Also, as seen in the following file: The last release where this issue still
exists is: 0.8.1
https://github.com/apache/kafka/blob/0.8.1/core/src/main/scala/kafka/network/BlockingChannel.scala
> 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
>Affects Versions: 0.8.1.1
>Reporter: Marc Chung
>Assignee: Marc Chung
> Fix For: 0.8.2.0, 0.9.0.0
>
> 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-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14211224#comment-14211224
]
Jun Rao commented on KAFKA-1733:
Since this is a small, but critical change, I double committed this to the
0.8.2 branch.
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-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14202276#comment-14202276
]
Solon Gordon commented on KAFKA-1733:
-
Any chance of getting this into a bugfix release sooner than 0.8.3? This seems
to significantly compromise Kafka's availability, since a single flaky broker
can cause all producers to block.
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-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14192003#comment-14192003
]
R. Tyler Croy commented on KAFKA-1733:
--
[~junrao] we are seeing this behavior against this client library version, fwiw:
{code}
dependency
groupIdorg.apache.kafka/groupId
artifactIdkafka_2.10/artifactId
version0.8.1.1/version
/dependency
{code}
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
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-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190765#comment-14190765
]
Jun Rao commented on KAFKA-1733:
Thanks for the patch. Could you generate a patch and attach it to the jira?
This will take care of the Apache licensing stuff.
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
This is a follow up to the conversation here:
https://mail-archives.apache.org/mod_mbox/kafka-dev/201409.mbox/%3ccaog_4qymoejhkbo0n31+a-ujx0z5unsisd5wbrmn-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190803#comment-14190803
]
R. Tyler Croy commented on KAFKA-1733:
--
[~junrao], the commit referenced is on top of the {{0.8.1.1}} release, do you
have a specific branch that we should target this patch with?
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
This is a follow up to the conversation here:
https://mail-archives.apache.org/mod_mbox/kafka-dev/201409.mbox/%3ccaog_4qymoejhkbo0n31+a-ujx0z5unsisd5wbrmn-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14190809#comment-14190809
]
Jun Rao commented on KAFKA-1733:
Since this doesn't seem to be an 0.8.2 blocker, let's patch this for trunk.
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
This is a follow up to the conversation here:
https://mail-archives.apache.org/mod_mbox/kafka-dev/201409.mbox/%3ccaog_4qymoejhkbo0n31+a-ujx0z5unsisd5wbrmn-xtx7gi...@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)
[jira] [Commented] (KAFKA-1733) Producer.send will block indeterminately when broker is unavailable.
[
https://issues.apache.org/jira/browse/KAFKA-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14185539#comment-14185539
]
Marc Chung commented on KAFKA-1733:
---
I have a patch (work in progress) here:
https://github.com/mchung/kafka/commit/87b8ddbfe23dc887f56fa6f9ea3669733933c49b
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: Jun Rao
This is a follow up to the conversation here:
https://mail-archives.apache.org/mod_mbox/kafka-dev/201409.mbox/%3ccaog_4qymoejhkbo0n31+a-ujx0z5unsisd5wbrmn-xtx7gi...@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)
