Reduce internal unsupported options in the Keycloak HA documentation

Closes #26068

Signed-off-by: Alexander Schwartz <aschwart@redhat.com>

docs/guides/high-availability/concepts-threads.adoc

@@ -27,11 +27,12 @@ When running on physical machines, adjust the number of worker threads to avoid
 Congestion would result in longer response times and an increased memory usage, and eventually an unstable system.
 
 Ideally, you should start with a low limit of threads and adjust it accordingly to the target throughput and response time.
-When the load and the number of threads increases, the bottleneck will usually be the database connections.
-Once a request cannot acquire a database connection, it will fail with a message in the log like `Unable to acquire JDBC Connection`.
+When the load and the number of threads increases, the bottleneck can become be the database connections.
+Once a request cannot acquire a database connection within 5 seconds, it will fail with a message in the log like `Unable to acquire JDBC Connection`.
 The caller will receive a response with a 5xx HTTP status code indicating a server side error.
 
-With the number of threads in the executor pool being an order of magnitude larger than the number of database connections and with requests failing when no database connection is available within the https://quarkus.io/guides/all-config#quarkus-agroal_quarkus.datasource.jdbc.acquisition-timeout[`quarkus.datasource.jdbc.acquisition-timeout`] (5 seconds default), this is somewhat of a https://en.wikipedia.org/wiki/Demand_response#Load_shedding[load-shedding behavior] where it returns an error response instead of queueing requests for an indefinite amount of time.
+If you increase the number of database connections and the number of threads too much, the system will be congested under a high load with requests queueing up and all callers getting a bad performance.
+Low numbers ensure fast response times for all clients, even if there is an occasionally failing request when there is a load spike.
 
 === JGroups connection pool
 

docs/guides/high-availability/deploy-keycloak-kubernetes.adoc

@@ -43,8 +43,6 @@ The number of all {project_name} threads in the StatefulSet should not exceed th
 You might consider limiting the number of {project_name} threads further because multiple concurrent threads will lead to throttling by Kubernetes once the requested CPU limit is reached.
 See the <@links.ha id="concepts-threads" /> {section} for details.
 <5> The JVM options set additional parameters:
-* `jgroups.thread_dumps_threshold` ensures that a log message "`thread pool is full`" appears once the JGroup thread pool is full for the first time.
-See the <@links.ha id="concepts-threads" /> {section} for details.
 * Adjust the memory settings for the heap.
 
 == Verifying the deployment

docs/guides/high-availability/examples/generated/keycloak-ispn.yaml

@@ -804,7 +804,7 @@ spec:
               # tag::keycloak-ispn[]
               - name: JAVA_OPTS_APPEND # <5>
                 value: >
-                  -Djgroups.thread_dumps_threshold=1 -Djboss.site.name=keycloak
+                  -Djboss.site.name=keycloak
 
                 # end::keycloak[]
                 # end::keycloak-ispn[]

docs/guides/high-availability/examples/generated/keycloak.yaml

@@ -480,7 +480,7 @@ spec:
               # tag::keycloak-ispn[]
               - name: JAVA_OPTS_APPEND # <5>
                 value: >
-                  -Xms512m -Xmx1524m -Djgroups.thread_dumps_threshold=1
+                  -Xms512m -Xmx1524m
 
                 # end::keycloak[]
                 # end::keycloak-ispn[]

docs/guides/high-availability/partials/threads/executor-jgroups-thread-calculation.adoc

@@ -1,3 +1,5 @@
-The number of JGroup threads is `200` by default, and can be configured using the property Java system property `jgroups.thread_pool.max_threads`.
-As shown in experiments, assuming a Keycloak cluster with 4 Pods, each Pod shouldn't have more than 50 worker threads so that it doesn't run out of threads in the JGroup thread pool of 200.
-Use the Quarkus configuration options `quarkus.thread-pool.max-threads` to configure the maximum number of worker threads.
+The number of JGroup threads is `200` by default.
+While it can be configured using the property Java system property `jgroups.thread_pool.max_threads`, we advise keeping it at this value.
+As shown in experiments, the total number of Quarkus worker threads in the cluster must not exceed the number of threads in the JGroup thread pool of 200 in each node to avoid deadlocks in the JGroups communication.
+Given a Keycloak cluster with four Pods, each Pod should then have 50 Quarkus worker threads.
+Use the Quarkus configuration options `quarkus.thread-pool.max-threads` to configure the maximum number of Quarkus worker threads.