[
https://issues.apache.org/jira/browse/KAFKA-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14999858#comment-14999858
]
Jason Gustafson commented on KAFKA-2805:
----------------------------------------
I was able to reproduce this following the steps from Luke Steensen's initial
e-mail:
{code}
# in separate terminals
$ ./bin/zookeeper-server-start.sh config/zookeeper.properties
$ ./bin/kafka-server-start.sh config/server.properties
# set request timeout
$ cat producer.properties
request.timeout.ms=1000
# run the verifiable producer, for example
$ ./bin/kafka-verifiable-producer.sh --broker-list localhost:9092 --topic
testing --throughput 5 --producer.config producer.properties
{code}
{quote}
If you then kill the kafka server process, you will see the producer hang
indefinitely. This is a very simple case, but the behavior is surprising.
We have also found it easy to reproduce this behavior in more realistic
environments with multiple brokers, custom producers, etc. The end result
is that we're not sure how to safely decommission a broker without
potentially leaving a producer with a permanently stuck request.
{quote}
> RecordAccumulator request timeout only enforced if partition leader is unknown
> ------------------------------------------------------------------------------
>
> Key: KAFKA-2805
> URL: https://issues.apache.org/jira/browse/KAFKA-2805
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Gustafson
> Assignee: Mayuresh Gharat
>
> From the user mailing list, the null check in batch expiration in
> RecordAccumulator seems questionable:
> https://github.com/apache/kafka/blob/ae5a5d7c08bb634576a414f6f2864c5b8a7e58a3/clients/src/main/java/org/apache/kafka/clients/producer/internals/RecordAccumulator.java#L220.
>
> If this is correct behavior, it is probably worthwhile clarifying the purpose
> of the check in a comment.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
