pasharik commented on code in PR #15830:
URL: https://github.com/apache/kafka/pull/15830#discussion_r1585713585
##########
core/src/main/scala/kafka/admin/AclCommand.scala:
##########
@@ -115,8 +115,6 @@ object AclCommand extends Logging {
val aclBindings = acls.map(acl => new AclBinding(resource,
acl)).asJavaCollection
adminClient.createAcls(aclBindings).all().get()
}
-
- listAcls(adminClient)
Review Comment:
Restored this print for now.
For me, this print together with checking for the output of this print
inside the test, causes kraft tests to be flaky. E.g.
```
./gradlew core:test --tests
"kafka.admin.AclCommandTest.testAclCliWithAdminAPI" --rerun
```
it always passes for `zk`, but quite often fails for `kraft`.
As I understand, `listAcls()` can be served by any broker in kraft mode, not
just by controller. So potentially some brokers may not have most up-to-date
copy of metadata right after `createAcls()` call. Here there is no interval
between `createAcls()` and `listAcls()`, so probability of such race condition
is higher.
From [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500)
and the
[diagram](https://cwiki.apache.org/confluence/download/attachments/123898922/b.png)
it seems what brokers have to periodically pull new metadata from the kraft
controller, so metadata is not available on all brokers immediately.
Please correct me if I'm wrong here.
I've looked at `TopicCommand`, as another example of the class which manages
metadata. It seems what it doesn't invoke `listTopics()` after creating or
deleting topics. So I thought we can use similar approach here.
I tried to reproduce this flaky behavior with running Kafka controller and
broker locally with `bin/kafka-server-start.sh`, and invoking
`bin/kafka-acls.sh` manually, but wasn't able to reproduce same issue.
Probably, it can be related to the test infrastructure setup. I'll try to
re-write the test to java and use new test infrastructure, let's see it solves
the issue
--
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-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
