Repository navigation
Update HA guide about non-blocking probes - #26783
Conversation
|
@mhajas - please review this PR when you have the time. When updating the docs I found that it was really hard to describe the behaviour. I was wondering if we could instead of making this probe always non-blocking a rely on a background task of the Agroal connection pool to check connections in the background. Still, that's a future issue if you agree that this would be good to have. Thanks! |
There was a problem hiding this comment.
Thank you for this PR @ahus1
Should we also update the first sentence in this section? https://github.com/keycloak/keycloak/blob/main/docs/guides/high-availability/concepts-threads.adoc#quarkus-executor-pool
If I understand correctly probes no longer run in the worker pool but directly in the event loop. Do I understand it correctly?
Also, about the suggestion for the truly non-blocking DB probe. I like the idea. Although, I am not sure whether it is critical. I am not sure what are all possible situations when the health check turn blocking but I beleive it will be only when current JDBC connections are all broken and new can't be established (is it correct?). In that case I think it is ok to block event-loop which will eventually kill the liveness probe.
Closes keycloak#26781 Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
da7642b to
404faa6
Compare
|
@mhajas - thank you for the review. I updated the first sentence of that paragraph to talk about "blocking probes". All blocking parts of the probes will be run on the executor pool, never on the event loop (which would be really bad as it would prevent any other parallel request to be processed). As it runs on the executor pool, it won't affect any liveness probe. I don't consider the blocking parts readiness probe critical. Still it introduces a complex behavior that is difficult to explain ("sometimes blocking, sometimes not") and reason about. It would need to be done in a separate issue, and IMHO won't make it into KC24. Ready for another round of review. |
Closes keycloak#26781 Signed-off-by: Alexander Schwartz <aschwart@redhat.com> Signed-off-by: Krzysztof Walczewski <kwalczewski@gmail.com>
Closes #26781