libre.sh/keycloak-scim
2
0
Fork 0
Code Issues 14 Pull requests Releases Packages Activity Actions 6

Update HA guide about non-blocking probes (#26783)

Browse source 
Closes #26781

Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
This commit is contained in:
Alexander Schwartz 2024-02-07 16:16:50 +01:00 committed by GitHub
parent d03b25b4b5
commit 786023fd06
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 6 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
docs/guides/high-availability/concepts-threads.adoc
View file

@ -16,7 +16,7 @@ For a configuration where this is applied, visit <@links.ha id="deploy-keycloak-
=== Quarkus executor pool
{project_name} requests, as well as all probes, are handled by the Quarkus executor pool.
{project_name} requests, as well as blocking probes, are handled by the Quarkus executor pool.
The Quarkus executor thread pool is configured in https://quarkus.io/guides/all-config#quarkus-core_quarkus.thread-pool.max-threads[`quarkus.thread-pool.max-threads`] and has a maximum size of at least 200 threads.
Depending on the available CPU cores, it can grow even larger.
@ -63,9 +63,11 @@ When this setting is active, requests that exceed the number of queued requests
[#probes]
=== Probes
All health probes are handled in the Quarkus executor worker pool by default.
Only the liveness probe is non-blocking.
Future version of {project_name} and Quarkus plan to have other probes also being non-blocking.
{project_name}'s liveness probe is non-blocking to avoid a restart of a Pod under a high load.
// Developer's note: See KeycloakReadyHealthCheck for the details of the blocking/non-blocking behavior
The overall health probe and the readiness can probe in some cases block to check the connection to the database, so they might fail under a high load.
Due to this, a Pod can become non-ready under a high load.
=== OS Resources