-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConcurrentModificationException in Cluster status code? #4639
Comments
And here's the output:
|
By looking at the code it seems this is happening because internal state from KS is being exposed without copying first (kafkaStreams.allMetadata()) |
fixes: confluentinc#4639 Until the Streams bug https://issues.apache.org/jira/browse/KAFKA-9668 is fixed, ksql needs to protect itself from ConcurrentMod exceptions when accessing `KafkaSteams.allMetadata`. This change accesses the internals of `KafkaStreams` to acquire a reference to the field that needs to be synchronised to protect against the concurrent modification.
This is still happening in 5.5 branch and master. see https://confluentinc.atlassian.net/browse/KSQL-4296 for an example |
fixes: confluentinc#4639 Until the Streams bug https://issues.apache.org/jira/browse/KAFKA-9668 is fixed, ksql needs to protect itself from ConcurrentMod exceptions when accessing `KafkaSteams.allMetadata`. This change accesses the internals of `KafkaStreams` to acquire a reference to the field that needs to be synchronised to protect against the concurrent modification.
Had a build failure that might suggest we've got a race condition in the new cluster status code:
Here's the job that failed:
https://jenkins.confluent.io/job/confluentinc-pr/job/ksql/job/PR-4638/1/testReport/junit/io.confluent.ksql.rest.integration/HeartbeatAgentFunctionalTest/shouldMarkRemoteServerAsUpThenDownThenUp/
The text was updated successfully, but these errors were encountered: