You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "frankvicky (via GitHub)" <gi...@apache.org> on 2026/07/21 15:42:59 UTC
[PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
frankvicky opened a new pull request, #22897:
URL: https://github.com/apache/kafka/pull/22897
This PR is a part of KIP-909.
It aims to apply the KIP-909 to Share Consumer.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "lianetm (via GitHub)" <gi...@apache.org>.
lianetm commented on code in PR #22897:
URL: https://github.com/apache/kafka/pull/22897#discussion_r3676160340
##########
clients/src/test/java/org/apache/kafka/clients/consumer/KafkaShareConsumerTest.java:
##########
@@ -409,4 +414,56 @@ private ShareAcknowledgeResponse shareAcknowledgeResponse(TopicIdPartition tip)
.setResponses(new ShareAcknowledgeResponseData.ShareAcknowledgeTopicResponseCollection(List.of(topicResponse)))
);
}
+
+ @Test
+ public void testShareConsumerBootstrapResolutionExceptionPropagatedToPoll() {
+ // Use an invalid hostname that will fail DNS resolution (using RFC 6761 reserved .invalid TLD)
+ String invalidHost = "unresolvable.invalid:9092";
+
+ Map<String, Object> configs = Map.of(
+ ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost,
+ // Set a short bootstrap timeout so the test doesn't take too long
+ CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000",
+ ConsumerConfig.GROUP_ID_CONFIG, "test-share-group"
+ );
+
+ KafkaShareConsumer<String, String> consumer = new KafkaShareConsumer<>(configs);
+ try {
+ consumer.subscribe(Set.of("test-topic"));
+
+ // Poll continuously until we get the BootstrapResolutionException
+ // The exception should be thrown after bootstrap.resolve.timeout.ms expires
+ BootstrapResolutionException exception =
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000; // 15 seconds max to prevent test hanging
+
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ consumer.poll(Duration.ofMillis(100));
+ }
+ fail("Expected BootstrapResolutionException to be thrown within " + maxWaitTime + "ms");
+ });
+
+ // Verify the exception message contains information about DNS resolution failure
+ assertTrue(exception.getMessage().contains("Failed to resolve bootstrap servers") ||
+ exception.getMessage().contains("DNS resolution"),
+ "Exception message should mention DNS resolution failure: " + exception.getMessage());
+
+ // After the first failure, any further API call must also throw. This guards against
+ // accidentally clearing the bootstrap error from the metadata layer.
+ assertThrows(BootstrapResolutionException.class, () -> consumer.poll(Duration.ofMillis(100)));
+ } finally {
+ // The graceful shutdown path itself triggers network I/O which will re-observe the
+ // permanent bootstrap failure and wrap it in KafkaException. That's expected for this
+ // test — we only care that the API-facing calls surface the bootstrap error, not
+ // that close() also completes cleanly under a broken bootstrap.
Review Comment:
not sure about this, do we want to propagate this on close? Does the regular consumer throw it?
I expect the async consumer doesn't (on close it only processes background events, and metadata error do not come as one there). As for the classic, not sure, but if let's say it wasn't able to resolve DNS and then close, even those close does poll, I'm not sure it would propagate the error? (it only polls for pending requests, which I imagine it wasn't able to generate if it didn't resolve the brokers).
So to confirm the behaviour , but if the consumers do not throw this on close as I imagine above, we shouldn't on the Share I would say, and it actually already filters out exceptions here
https://github.com/apache/kafka/blob/74ef4dd97aa68ca30a3992f59d12fd0f7a0ff2ac/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ShareConsumerImpl.java#L1098-L1099
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "lianetm (via GitHub)" <gi...@apache.org>.
lianetm commented on code in PR #22897:
URL: https://github.com/apache/kafka/pull/22897#discussion_r3676160340
##########
clients/src/test/java/org/apache/kafka/clients/consumer/KafkaShareConsumerTest.java:
##########
@@ -409,4 +414,56 @@ private ShareAcknowledgeResponse shareAcknowledgeResponse(TopicIdPartition tip)
.setResponses(new ShareAcknowledgeResponseData.ShareAcknowledgeTopicResponseCollection(List.of(topicResponse)))
);
}
+
+ @Test
+ public void testShareConsumerBootstrapResolutionExceptionPropagatedToPoll() {
+ // Use an invalid hostname that will fail DNS resolution (using RFC 6761 reserved .invalid TLD)
+ String invalidHost = "unresolvable.invalid:9092";
+
+ Map<String, Object> configs = Map.of(
+ ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost,
+ // Set a short bootstrap timeout so the test doesn't take too long
+ CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000",
+ ConsumerConfig.GROUP_ID_CONFIG, "test-share-group"
+ );
+
+ KafkaShareConsumer<String, String> consumer = new KafkaShareConsumer<>(configs);
+ try {
+ consumer.subscribe(Set.of("test-topic"));
+
+ // Poll continuously until we get the BootstrapResolutionException
+ // The exception should be thrown after bootstrap.resolve.timeout.ms expires
+ BootstrapResolutionException exception =
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000; // 15 seconds max to prevent test hanging
+
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ consumer.poll(Duration.ofMillis(100));
+ }
+ fail("Expected BootstrapResolutionException to be thrown within " + maxWaitTime + "ms");
+ });
+
+ // Verify the exception message contains information about DNS resolution failure
+ assertTrue(exception.getMessage().contains("Failed to resolve bootstrap servers") ||
+ exception.getMessage().contains("DNS resolution"),
+ "Exception message should mention DNS resolution failure: " + exception.getMessage());
+
+ // After the first failure, any further API call must also throw. This guards against
+ // accidentally clearing the bootstrap error from the metadata layer.
+ assertThrows(BootstrapResolutionException.class, () -> consumer.poll(Duration.ofMillis(100)));
+ } finally {
+ // The graceful shutdown path itself triggers network I/O which will re-observe the
+ // permanent bootstrap failure and wrap it in KafkaException. That's expected for this
+ // test — we only care that the API-facing calls surface the bootstrap error, not
+ // that close() also completes cleanly under a broken bootstrap.
Review Comment:
not sure about this, do we want to propagate this on close? Does the regular consumer throw it?
I expect the async consumer doesn't (on close it only processes background events, and metadata error do not come as one there). As for the classic, not sure, but if let's say it wasn't able to resolve DNS and then close, even though close does poll, I'm not sure it would propagate the error? (it only polls for pending requests, which I imagine it wasn't able to generate if it didn't resolve the brokers).
So to confirm the behaviour , but if the consumers do not throw this on close as I imagine above, we shouldn't on the Share I would say, and it actually already filters out exceptions here
https://github.com/apache/kafka/blob/74ef4dd97aa68ca30a3992f59d12fd0f7a0ff2ac/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ShareConsumerImpl.java#L1098-L1099
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #22897:
URL: https://github.com/apache/kafka/pull/22897#discussion_r3636337251
##########
clients/src/main/java/org/apache/kafka/clients/NetworkClient.java:
##########
@@ -835,6 +909,21 @@ public LeastLoadedNode leastLoadedNode(long now) {
}
}
+ /**
+ * Handle the case when there are no nodes available.
+ * <p>
+ * If bootstrap is disabled or already complete, throw IllegalStateException.
+ * If bootstrap is enabled but not yet complete, return null to allow DNS resolution to continue.
Review Comment:
This Javadoc says to “return null” during bootstrap, but the method returns a LeastLoadedNode instance with a null node. Update the comment to match the actual behavior.
This issue also appears in the following locations of the same file:
- line 1335
- line 1340
- line 1365
##########
clients/src/test/java/org/apache/kafka/clients/admin/KafkaAdminClientTest.java:
##########
@@ -11881,4 +11880,34 @@ public void testOutOfMemoryErrorPropagation() throws Exception {
TestUtils.assertFutureThrows(OutOfMemoryError.class, result.names());
}
}
+
+ @Test
+ public void testAdminBootstrapResolutionExceptionPropagated() throws Exception {
+ String invalidHost = "unresolvable.invalid:9092";
+ Map<String, Object> configs = new HashMap<>();
+ configs.put(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost);
+ configs.put(CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000");
+
+ try (Admin admin = Admin.create(configs)) {
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000;
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ try {
+ admin.listTopics().names().get();
+ } catch (ExecutionException e) {
+ if (e.getCause() instanceof BootstrapResolutionException) {
+ throw (BootstrapResolutionException) e.getCause();
+ }
+ }
+ }
Review Comment:
This while-loop may spin very fast when listTopics().names().get() fails quickly (e.g., before the bootstrap timeout is reached), consuming CPU unnecessarily. Adding a small backoff makes the test less resource-intensive while still bounding runtime.
##########
clients/src/main/java/org/apache/kafka/clients/admin/KafkaAdminClient.java:
##########
@@ -516,6 +516,43 @@ static String prettyPrintException(Throwable throwable) {
return throwable.getClass().getSimpleName();
}
+ /**
+ * Determines which bootstrap configuration to use based on the provided config.
+ * Validates that exactly one of bootstrap.servers or bootstrap.controllers is configured.
+ *
+ * @param config The admin client configuration
+ * @return true if using bootstrap.controllers, false if using bootstrap.servers
+ * @throws ConfigException if both or neither bootstrap configurations are set
+ */
+ static boolean determineBootstrapType(AdminClientConfig config) {
+ List<String> bootstrapServers = config.getList(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG);
+ if (bootstrapServers == null) {
+ bootstrapServers = Collections.emptyList();
+ }
Review Comment:
determineBootstrapType introduces new validation logic for bootstrap.servers vs bootstrap.controllers, but the dedicated unit tests that previously covered this behavior (AdminBootstrapAddressesTest) were removed. Add focused tests to cover the three cases: neither set, both set, and exactly one set.
##########
clients/src/test/java/org/apache/kafka/clients/NetworkClientTest.java:
##########
@@ -1630,4 +1654,110 @@ public KafkaException getAndClearFailure() {
return failure;
}
}
+
+ private void bootstrapMetadataWithNodes(Metadata metadata, List<Node> nodes) {
+ List<InetSocketAddress> serverAddresses = new ArrayList<>();
+ nodes.forEach(node -> serverAddresses.add(new InetSocketAddress(node.host(), node.port())));
+ metadata.bootstrap(serverAddresses);
+ }
+
+ private void bootstrapMetadata(Metadata metadata) {
+ List<InetSocketAddress> serverAddresses = new ArrayList<>(List.of(
+ new InetSocketAddress("localhost0", 8000),
+ new InetSocketAddress("localhost1", 8000)
+ ));
+ metadata.bootstrap(serverAddresses);
+ }
+
+ private void bootstrapMetadataUpdater(final MetadataUpdater metadataUpdater) {
+ List<InetSocketAddress> serverAddresses = new ArrayList<>(List.of(
+ new InetSocketAddress("localhost0", 8000),
+ new InetSocketAddress("localhost1", 8000)
+ ));
+ metadataUpdater.bootstrap(serverAddresses);
+ }
Review Comment:
These helpers use new InetSocketAddress("localhost0", …) / ("localhost1", …), which can trigger real DNS lookups during tests. Using InetSocketAddress.createUnresolved avoids external DNS dependency and speeds up/derisks the test suite.
##########
clients/src/test/java/org/apache/kafka/clients/producer/KafkaProducerTest.java:
##########
@@ -3416,4 +3424,59 @@ public static void resetCounters() {
CLOSE_COUNT.set(0);
}
}
+
+ @Test
+ public void testProducerBootstrapResolutionExceptionPropagated() {
+ String invalidHost = "unresolvable.invalid:9092";
+ Map<String, Object> configs = Map.of(
+ ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName(),
+ ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName(),
+ CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost,
+ CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000"
+ );
+
+ try (KafkaProducer<String, String> producer = new KafkaProducer<>(configs)) {
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000;
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ producer.partitionsFor("test-topic");
+ }
Review Comment:
This loop can become a tight spin if partitionsFor() returns quickly before the bootstrap timeout elapses, which can waste CPU and make the test noisy under load. Adding a small sleep/backoff makes the test friendlier and still validates the behavior.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "lianetm (via GitHub)" <gi...@apache.org>.
lianetm commented on code in PR #22897:
URL: https://github.com/apache/kafka/pull/22897#discussion_r3676160340
##########
clients/src/test/java/org/apache/kafka/clients/consumer/KafkaShareConsumerTest.java:
##########
@@ -409,4 +414,56 @@ private ShareAcknowledgeResponse shareAcknowledgeResponse(TopicIdPartition tip)
.setResponses(new ShareAcknowledgeResponseData.ShareAcknowledgeTopicResponseCollection(List.of(topicResponse)))
);
}
+
+ @Test
+ public void testShareConsumerBootstrapResolutionExceptionPropagatedToPoll() {
+ // Use an invalid hostname that will fail DNS resolution (using RFC 6761 reserved .invalid TLD)
+ String invalidHost = "unresolvable.invalid:9092";
+
+ Map<String, Object> configs = Map.of(
+ ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost,
+ // Set a short bootstrap timeout so the test doesn't take too long
+ CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000",
+ ConsumerConfig.GROUP_ID_CONFIG, "test-share-group"
+ );
+
+ KafkaShareConsumer<String, String> consumer = new KafkaShareConsumer<>(configs);
+ try {
+ consumer.subscribe(Set.of("test-topic"));
+
+ // Poll continuously until we get the BootstrapResolutionException
+ // The exception should be thrown after bootstrap.resolve.timeout.ms expires
+ BootstrapResolutionException exception =
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000; // 15 seconds max to prevent test hanging
+
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ consumer.poll(Duration.ofMillis(100));
+ }
+ fail("Expected BootstrapResolutionException to be thrown within " + maxWaitTime + "ms");
+ });
+
+ // Verify the exception message contains information about DNS resolution failure
+ assertTrue(exception.getMessage().contains("Failed to resolve bootstrap servers") ||
+ exception.getMessage().contains("DNS resolution"),
+ "Exception message should mention DNS resolution failure: " + exception.getMessage());
+
+ // After the first failure, any further API call must also throw. This guards against
+ // accidentally clearing the bootstrap error from the metadata layer.
+ assertThrows(BootstrapResolutionException.class, () -> consumer.poll(Duration.ofMillis(100)));
+ } finally {
+ // The graceful shutdown path itself triggers network I/O which will re-observe the
+ // permanent bootstrap failure and wrap it in KafkaException. That's expected for this
+ // test — we only care that the API-facing calls surface the bootstrap error, not
+ // that close() also completes cleanly under a broken bootstrap.
Review Comment:
not sure about this, do we want to propagate this on close? Does the regular consumer throw it?
I expect the async consumer doesn't (on close it only processes background events, and metadata error do not come as one there). As for the classic, not sure, but if let's say it wasn't able to resolve DNS and then close, even those close does poll, I'm not sure it would propagate the error? (it only polls for pending requests, which I imagine it wasn't able to generate if it didn't resolve the brokers).
So to confirm the behaviour , but if the consumers do not throw this on close as I imagine above, we shouldn't on the Share I would say, and it actually already filters out exceptions here
The share does swallow some errors on close that are considered not relevant anymore, https://github.com/apache/kafka/blob/74ef4dd97aa68ca30a3992f59d12fd0f7a0ff2ac/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ShareConsumerImpl.java#L1098-L1099
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "frankvicky (via GitHub)" <gi...@apache.org>.
frankvicky commented on code in PR #22897:
URL: https://github.com/apache/kafka/pull/22897#discussion_r3676275815
##########
clients/src/test/java/org/apache/kafka/clients/consumer/KafkaShareConsumerTest.java:
##########
@@ -409,4 +414,56 @@ private ShareAcknowledgeResponse shareAcknowledgeResponse(TopicIdPartition tip)
.setResponses(new ShareAcknowledgeResponseData.ShareAcknowledgeTopicResponseCollection(List.of(topicResponse)))
);
}
+
+ @Test
+ public void testShareConsumerBootstrapResolutionExceptionPropagatedToPoll() {
+ // Use an invalid hostname that will fail DNS resolution (using RFC 6761 reserved .invalid TLD)
+ String invalidHost = "unresolvable.invalid:9092";
+
+ Map<String, Object> configs = Map.of(
+ ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName(),
+ CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, invalidHost,
+ // Set a short bootstrap timeout so the test doesn't take too long
+ CommonClientConfigs.BOOTSTRAP_RESOLVE_TIMEOUT_MS_CONFIG, "3000",
+ ConsumerConfig.GROUP_ID_CONFIG, "test-share-group"
+ );
+
+ KafkaShareConsumer<String, String> consumer = new KafkaShareConsumer<>(configs);
+ try {
+ consumer.subscribe(Set.of("test-topic"));
+
+ // Poll continuously until we get the BootstrapResolutionException
+ // The exception should be thrown after bootstrap.resolve.timeout.ms expires
+ BootstrapResolutionException exception =
+ assertThrows(BootstrapResolutionException.class, () -> {
+ long startTime = System.currentTimeMillis();
+ long maxWaitTime = 15000; // 15 seconds max to prevent test hanging
+
+ while (System.currentTimeMillis() - startTime < maxWaitTime) {
+ consumer.poll(Duration.ofMillis(100));
+ }
+ fail("Expected BootstrapResolutionException to be thrown within " + maxWaitTime + "ms");
+ });
+
+ // Verify the exception message contains information about DNS resolution failure
+ assertTrue(exception.getMessage().contains("Failed to resolve bootstrap servers") ||
+ exception.getMessage().contains("DNS resolution"),
+ "Exception message should mention DNS resolution failure: " + exception.getMessage());
+
+ // After the first failure, any further API call must also throw. This guards against
+ // accidentally clearing the bootstrap error from the metadata layer.
+ assertThrows(BootstrapResolutionException.class, () -> consumer.poll(Duration.ofMillis(100)));
+ } finally {
+ // The graceful shutdown path itself triggers network I/O which will re-observe the
+ // permanent bootstrap failure and wrap it in KafkaException. That's expected for this
+ // test — we only care that the API-facing calls surface the bootstrap error, not
+ // that close() also completes cleanly under a broken bootstrap.
Review Comment:
Great catch — verified the classic & async consumers already handle this cleanly (`KafkaConsumerTest.testConsumerBootstrapResolutionExceptionPropagatedToPoll` uses try-with-resources and `close()` doesn't throw), so Share was the odd one out.
The Share close path hits `sendAcknowledgementsAndLeaveGroup` → `processBackgroundEvents(unsubscribeEvent.future(), timer, filter)`, and the filter only ignored `GroupAuthorizationException / TopicAuthorizationException / InvalidTopicException`, so a `BootstrapResolutionException` on the unsubscribe future bubbled up and was captured into `firstException`, which then produced the wrapping `KafkaException` at the end of close().
Added `BootstrapResolutionException` to that ignore predicate (matches the intent you highlighted — the filter is exactly the right place). Now close() completes cleanly under a broken bootstrap, and I removed the `try/catch` wrapper from the test so it's consistent with the classic/async test's try-with-resources pattern.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] KAFKA-14648: Do not fail clients if bootstrap servers is not immediately resolvable (2/2) [kafka]
Posted by "frankvicky (via GitHub)" <gi...@apache.org>.
frankvicky merged PR #22897:
URL: https://github.com/apache/kafka/pull/22897
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org