-
Notifications
You must be signed in to change notification settings - Fork 50
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
Try to speed up kafka admin CLI invocations #25
Conversation
based on the observation that, bar custom env, the analysis done at every start is static. Utilities that run as for example kube jobs could be speedier if we mod the entrypoint.
Might still be useful becasue it hides the hideous classpath string and is less picky than regular java invocations in CLI args ordering
but why does it require the lz4 lib at all for mere topic admin? The stack trace indicates an issue in CompressionType which could be what is worked around in https://github.com/quarkusio/quarkus/tree/0.16/extensions/kafka-client/runtime/src/main/java/io/quarkus/kafka/client/runtime/graal Can we instead block analysis before it ends up in CompressionType stuff, for the topic admin use case?
... and with these resource limits it takes ~20s on my local dev cluster.
|
Caused by: java.lang.InstantiationException: Type `sun.security.provider.ConfigFile` can not be instantiated reflectively as it does not have a no-parameter constructor or the no-parameter constructor has not been added explicitly to the native image.
"or the no-parameter constructor has not been added explicitly to the native image"
…le in state: CONNECTING
com.fasterxml.jackson.databind.ext.Java7Support <clinit> WARNING: Unable to load JDK7 types (annotations, java.nio.file.Path): no Java7 support added
but I don't want to change download paths now and here we're not using it as a runtime image.
back to a reduced classpath: Discovered unresolved type during parsing: io.netty.util.internal.logging.Log4J2Logger
Did some experiments with Kafka 2.4.0 (as Yolean/kubernetes-kafka#297 says it would be great to not have to specify replication factor and partitions in topic-create jobs) but I think we should wait until Quarkus is at Graal 19.3.0 and Kafka 2.4.0. Currently builds fail with:
|
#29 builds on the discoveries from this PR and produces up to date images |
... using native image ideally. If that fails a small improvement might be achieved by bypassing the shell wrapper and reducing the volume of classpath libs.
./bin/kafka-topics.sh
tokafka-topics
is the first step, but it currently fails on GraalVM native-image with jopt-simple.