It's not something which happens often but when on heavy load or with less CPU resources, at least while working on my laptop within minikube, it happens that during certificates generation the Vert.x thread checker kicks in, because such operation is taking longer than the max default of 2000 ms.
Looking at the code, all openssl operations are executed by using a Process.waitFor() call here https://github.com/strimzi/strimzi-kafka-operator/blob/main/certificate-manager/src/main/java/io/strimzi/certs/OpenSslCertManager.java#L681 but always within the Vert.x thread event loop. Going back through the calls chain I can't see the usage of a Vert.x executeBlocking() call to use a worker thread instead.
I would assume something like this should not happen in production with better infrastructure and CPU resources but in general I think it's not good executing such operations on the Vert.x event loop anyway, as an anti-pattern.
It's not something which happens often but when on heavy load or with less CPU resources, at least while working on my laptop within minikube, it happens that during certificates generation the Vert.x thread checker kicks in, because such operation is taking longer than the max default of 2000 ms.
Looking at the code, all openssl operations are executed by using a
Process.waitFor()call here https://github.com/strimzi/strimzi-kafka-operator/blob/main/certificate-manager/src/main/java/io/strimzi/certs/OpenSslCertManager.java#L681 but always within the Vert.x thread event loop. Going back through the calls chain I can't see the usage of a Vert.xexecuteBlocking()call to use a worker thread instead.I would assume something like this should not happen in production with better infrastructure and CPU resources but in general I think it's not good executing such operations on the Vert.x event loop anyway, as an anti-pattern.