I have tracked down the H2 implementation, and the postgresql version as well. The JDBC docs say that the tableName parameter is not a pattern. Other methods on that interface do take patterns, but getImportedKeys does not. So this line using ‘%’ is wrong. In H2, the loop logic does not support pattern lookups at all. In postgresql, however, there is wildcard support, but one must pass in the empty string; looking at the postgresql line referenced, you can see that the generated sql uses ‘=’, not LIKE.
Locallly, I switched to use “” instead of “%” for postgresql, and it removed 8s from the startup time.
Total time wasn’t the point of this(it’s now down to 7.5s), but it took 8s between 2 log lines in moqui(when it was fetching all the foreign key references from the database). And yes, working on a PR. My desire would be to have a per-database-type way to specify how to do a wildcard key fetch(if supported).
My current goal, beyond just this discussion, is to get health check endpoints responding very early, and not have to wait for the rest of moqui to initialize.
I guess the question there is what is needed to happen before it’s even worth returning a health check. Almost certainly a correct database connection, open search connection, and if Moqui is in a clustered mode then a connection to other Moqui instances on the network through hazelcast.
There are 3 probes. Start, which can take a long time when the pod is first loaded, and the liveness/readiness probes won’t begin until start is ok. Start can have a longer set of retry parameters.
Liveness and readiness then are very similar. Liveness means the system is working correctly, without errors, while readiness means the pod can handle requests. If liveness reports ok, but readiness does not, k8s will direct traffic to a different backend, by taking the current pod out of rotation. That could be useful if the pod needs to do some housecleaning or some such, that requires more resources or something.