[
https://issues.apache.org/jira/browse/KAFKA-8370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16947064#comment-16947064
]
Chris Egerton edited comment on KAFKA-8370 at 10/8/19 5:24 PM:
---------------------------------------------------------------
[~rhauch] is this still an issue, and if so, do we still want to implement the
fix suggested on this ticket (checking if the topic exists before attempting to
create it)?
Checking to see if the topic exists before creating it would prevent some
unnecessary topic creation requests (in fact, probably most), but it wouldn't
prevent the possible race condition where two workers perform the check at the
same time, see that the topic doesn't exist, and then both attempt to create
the topic. With fixes like https://issues.apache.org/jira/browse/KAFKA-6250 and
https://issues.apache.org/jira/browse/KAFKA-7633, it's unclear if sending
unnecessary topic creation requests is a serious issue anymore since Connect
should still function properly if they fail.
If we don't aim to implement a fix for this issue, then the ticket should be
closed. Otherwise, it'd be good to clarify what the impact of this issue is
after taking into account the aforementioned tickets which lessened the impact
of failed topic create requests.
was (Author: chrisegerton):
[~rhauch] is this still an issue, and if so, do we still want to implement it
in the way suggested on this ticket (checking if the topic exists before
attempting to create it)?
Checking to see if the topic exists before creating it would prevent some
unnecessary topic creation requests (in fact, probably most), but it wouldn't
prevent the possible race condition where two workers perform the check at the
same time, see that the topic doesn't exist, and then both attempt to create
the topic. With fixes like https://issues.apache.org/jira/browse/KAFKA-6250 and
https://issues.apache.org/jira/browse/KAFKA-7633, it's unclear if sending
unnecessary topic creation requests is a serious issue anymore since Connect
should still function properly if they fail.
If we don't aim to implement a fix for this issue, then the ticket should be
closed. Otherwise, it'd be good to clarify what the impact of this issue is
after taking into account the aforementioned tickets which lessened the impact
of failed topic create requests.
> Kafka Connect should check for existence of internal topics before attempting
> to create them
> --------------------------------------------------------------------------------------------
>
> Key: KAFKA-8370
> URL: https://issues.apache.org/jira/browse/KAFKA-8370
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Affects Versions: 0.11.0.0
> Reporter: Randall Hauch
> Assignee: Randall Hauch
> Priority: Major
>
> The Connect worker doesn't current check for the existence of the internal
> topics, and instead is issuing a CreateTopic request and handling a
> TopicExistsException. However, this can cause problems when the number of
> brokers is fewer than the replication factor, *even if the topic already
> exists* and the partitions of those topics all remain available on the
> remaining brokers.
> One problem of the current approach is that the broker checks the requested
> replication factor before checking for the existence of the topic, resulting
> in unexpected exceptions when the topic does exist:
> {noformat}
> connect | [2019-05-14 19:24:25,166] ERROR Uncaught exception in herder
> work thread, exiting:
> (org.apache.kafka.connect.runtime.distributed.DistributedHerder)
> connect | org.apache.kafka.connect.errors.ConnectException: Error while
> attempting to create/find topic(s) 'connect-offsets'
> connect | at
> org.apache.kafka.connect.util.TopicAdmin.createTopics(TopicAdmin.java:255)
> connect | at
> org.apache.kafka.connect.storage.KafkaOffsetBackingStore$1.run(KafkaOffsetBackingStore.java:99)
> connect | at
> org.apache.kafka.connect.util.KafkaBasedLog.start(KafkaBasedLog.java:127)
> connect | at
> org.apache.kafka.connect.storage.KafkaOffsetBackingStore.start(KafkaOffsetBackingStore.java:109)
> connect | at
> org.apache.kafka.connect.runtime.Worker.start(Worker.java:164)
> connect | at
> org.apache.kafka.connect.runtime.AbstractHerder.startServices(AbstractHerder.java:114)
> connect | at
> org.apache.kafka.connect.runtime.distributed.DistributedHerder.run(DistributedHerder.java:214)
> connect | at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> connect | at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> connect | at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> connect | at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> connect | at java.lang.Thread.run(Thread.java:748)
> connect | Caused by: java.util.concurrent.ExecutionException:
> org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication
> factor: 3 larger than available brokers: 2.
> connect | at
> org.apache.kafka.common.internals.KafkaFutureImpl.wrapAndThrow(KafkaFutureImpl.java:45)
> connect | at
> org.apache.kafka.common.internals.KafkaFutureImpl.access$000(KafkaFutureImpl.java:32)
> connect | at
> org.apache.kafka.common.internals.KafkaFutureImpl$SingleWaiter.await(KafkaFutureImpl.java:89)
> connect | at
> org.apache.kafka.common.internals.KafkaFutureImpl.get(KafkaFutureImpl.java:260)
> connect | at
> org.apache.kafka.connect.util.TopicAdmin.createTopics(TopicAdmin.java:228)
> connect | ... 11 more
> connect | Caused by:
> org.apache.kafka.common.errors.InvalidReplicationFactorException: Replication
> factor: 3 larger than available brokers: 2.
> connect | [2019-05-14 19:24:25,168] INFO Kafka Connect stopping
> (org.apache.kafka.connect.runtime.Connect)
> {noformat}
> Instead of always issuing a CreateTopic request, the worker's admin client
> should first check whether the topic exists, and if not *then* attempt to
> create the topic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
