[
https://issues.apache.org/jira/browse/KAFKA-7924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gert van Dijk updated KAFKA-7924:
---------------------------------
Description:
Steps to reproduce:
# Start single Zookeeper instance.
# Start single Kafka instance.
# Validate that the line {noformat}INFO [KafkaServer id=0] started
(kafka.server.KafkaServer){noformat} is printed.
# Connect using a Kafka client +with debug logging enabled+, right after seeing
that line, _do not wait_.
# Observe that it is connected to the Kafka broker just fine, but that the
broker lists an +empty lists of nodes+: {noformat}Updating cluster metadata to
Cluster(id = xxx, nodes = [], [...]{noformat}
# Keep watching for about 30 seconds, seeing that log entry popping up hundreds
of times on the client. Nothing happens in Kafka/Zookeeper logs in the
meantime, but then suddenly the Kafka server start reporting nodes to the
connected client: {noformat}[...] nodes = [kafka:9092 (id: 0 rack: null)], [...]
o.apache.kafka.clients.NetworkClient - [AdminClient clientId=adminclient-1]
Initiating connection to node [...]{noformat} and it connects all fine.
My expectation is that it should list itself rightaway after listening on the
network as a broker. It should not take ~ 30 seconds for a Kafka client to be
blocked waiting and timing out first.
Use case: I'm trying to create topics in a CI/CD pipeline and spinning up a
clean Kafka for that. Right after it's started, it should be possible to create
topics using an AdminClient, but currently experiencing {{TimeoutException:
Timed out waiting for a node assignment}} errors unless I put a {{sleep 30}}
between observing a Kafka reportedly ready and starting the topic creation
process. Not very ideal.
was:
Steps to reproduce:
# Start single Zookeeper instance.
# Start single Kafka instance.
# Validate that the line {noformat}INFO [KafkaServer id=0] started
(kafka.server.KafkaServer){noformat} is printed.
# Connect using a Kafka client +with debug logging enabled+, right after seeing
that line, _do not wait_.
# Observe that it is connected to the Kafka broker just fine, but that the
broker lists an empty lists of nodes: {noformat}Updating cluster metadata to
Cluster(id = xxx, nodes = [], [...]{noformat}
# Keep watching for about 30 seconds, seeing that log entry popping up hundreds
of times. Nothing happens in Kafka/Zookeeper logs in the meantime, but then
suddenly the Kafka server start reporting nodes to the connected client:
{noformat}[...] nodes = [kafka:9092 (id: 0 rack: null)], [...]
o.apache.kafka.clients.NetworkClient - [AdminClient clientId=adminclient-1]
Initiating connection to node [...]{noformat} and it connects all fine.
My expectation is that it should list itself rightaway after listening on the
network as a broker. It should not take ~ 30 seconds for a Kafka client to be
blocked waiting and timing out first.
Use case: I'm trying to create topics in a CI/CD pipeline and spinning up a
clean Kafka for that. Right after it's started, it should be possible to create
topics using an AdminClient, but currently experiencing {{TimeoutException:
Timed out waiting for a node assignment}} errors unless I put a {{sleep 30}}
between observing a Kafka reportedly ready and starting the topic creation
process. Not very ideal.
> Kafka broker does not list nodes first ~ 30s after startup
> ----------------------------------------------------------
>
> Key: KAFKA-7924
> URL: https://issues.apache.org/jira/browse/KAFKA-7924
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 2.1.0
> Environment: Clean Docker environment, very simple everything single
> node.
> Reporter: Gert van Dijk
> Priority: Major
>
> Steps to reproduce:
> # Start single Zookeeper instance.
> # Start single Kafka instance.
> # Validate that the line {noformat}INFO [KafkaServer id=0] started
> (kafka.server.KafkaServer){noformat} is printed.
> # Connect using a Kafka client +with debug logging enabled+, right after
> seeing that line, _do not wait_.
> # Observe that it is connected to the Kafka broker just fine, but that the
> broker lists an +empty lists of nodes+: {noformat}Updating cluster metadata
> to Cluster(id = xxx, nodes = [], [...]{noformat}
> # Keep watching for about 30 seconds, seeing that log entry popping up
> hundreds of times on the client. Nothing happens in Kafka/Zookeeper logs in
> the meantime, but then suddenly the Kafka server start reporting nodes to the
> connected client: {noformat}[...] nodes = [kafka:9092 (id: 0 rack: null)],
> [...]
> o.apache.kafka.clients.NetworkClient - [AdminClient clientId=adminclient-1]
> Initiating connection to node [...]{noformat} and it connects all fine.
> My expectation is that it should list itself rightaway after listening on the
> network as a broker. It should not take ~ 30 seconds for a Kafka client to be
> blocked waiting and timing out first.
> Use case: I'm trying to create topics in a CI/CD pipeline and spinning up a
> clean Kafka for that. Right after it's started, it should be possible to
> create topics using an AdminClient, but currently experiencing
> {{TimeoutException: Timed out waiting for a node assignment}} errors unless I
> put a {{sleep 30}} between observing a Kafka reportedly ready and starting
> the topic creation process. Not very ideal.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
