Jetty configuration properties
|
In IDM 8.0, When serving SSL requests, Jetty 12 checks that the incoming host header matches the server certificate’s subject and returns a Learn more in Jetty 12 support. |
The configuration for PingIDM’s embedded Jetty web server includes a webserver.json and a webserver.listener-*.json.
By default, the Jetty web server uses the HTTP, SSL, and Mutual Authentication ports defined in IDM.
| The default settings are intended for evaluation only. Adjust them according to your production requirements. |
Jetty property reference
| Field | Description | Default value |
|---|---|---|
|
The maximum number of threads used to handle requests. |
|
|
The maximum number of requests allowed in the QoSHandler queue. This setting controls readiness probe behavior. |
The default value allows for an unbounded queue. |
The number of milliseconds a request can remain in the QosHandler queue. |
The default value allows requests to remain in the unbounded queue indefinitely. |
|
|
Contains the settings for the global Gzip compression handler. |
|
|
Toggles the Gzip compression handler on or off. |
|
|
The minimum response size in bytes required to enable compression of the response. |
|
|
The size in bytes of the buffer used to inflate compressed requests. |
|
|
Toggles the usage of the SYNC_FLUSH mode when compressing responses. |
|
|
The allow list of HTTP methods that compression will be applied to. |
|
|
The block list of HTTP methods that compression will not be applied to. |
| Field | Description | Default value |
|---|---|---|
|
Toggles the listener on or off. |
|
|
The port to listen to. |
|
|
Toggles the use of TLS on or off. |
|
|
Toggles the use of |
|
|
Toggles the When This enables support for mixed traffic, allowing clients with or without certificates to connect on the same port. For proper function, you must set |
|
|
The key alias IDM uses when choosing the certificate to present for HTTPS connections. |
|
|
The allow-list of acceptable TLS protocols. |
|
|
The block-list of non-acceptable TLS protocols. |
|
|
The allow-list of acceptable TLS ciphers. |
|
|
The block-list of non-acceptable TLS ciphers. |
|
|
The number of threads used to accept TCP socket connections. Learn more in the Jetty description of acceptor threads. |
|
|
The number of threads used to manage the set of accepted TCP sockets. Learn more in the Jetty description of selector threads. |
|
|
The amount of time to wait in milliseconds before closing a connection if no data has been sent or received. |
|
|
The maximum size in bytes of a server response buffer. |
|
|
The maximum size in bytes of the client request buffer. |
|
|
The maximum size in bytes of the response and request header buffers. |
|
|
Toggles the Jetty SNI host check. When enabled, Jetty checks that the incoming host header matches the server certificate’s subject. This setting does nothing if |
|
|
Toggles the handling of proxied requests. Enable this property when running IDM behind a proxy or load balancer. |
|
Graceful shutdown
When IDM shuts down, whether triggered by a SIGTERM signal, a shutdown command, or a platform-specific stop mechanism such as a Windows service shutdown, the embedded Jetty web server shuts down gracefully:
-
IDM adds a
Connection: closeheader to in-flight HTTP responses, signaling clients to close keep-alive connections. -
IDM tells Jetty to stop accepting new connections.
-
IDM waits, up to a configurable timeout, for Jetty’s in-flight requests to complete (
idm.shutdown.jetty.timeout.seconds). -
IDM forcefully closes any remaining active Jetty connections and completes the shutdown.
This behavior prevents clients from receiving abrupt connection failures or 404 responses while IDM is shutting down, which is especially important in clustered or load-balanced deployments.
Graceful shutdown timeout
The idm.shutdown.jetty.timeout.seconds system property controls how long IDM waits for Jetty’s in-flight requests to complete before stopping connections.
Default |
|
Positive integer |
Wait up to this many seconds for in-flight requests to complete, then stop connections. |
|
Skip the wait. IDM stops Jetty immediately on a shutdown signal, without waiting for in-flight requests to complete. |
If your deployment enforces a shutdown deadline, set it to at least idm.shutdown.jetty.timeout.seconds plus any pre-stop sleep so IDM can finish draining before it’s terminated. For example, in Kubernetes, set terminationGracePeriodSeconds to that value.
You can set the property using:
-
.propertiesfile -
OPENIDM_OPTSenvironment variable
idm.shutdown.jetty.timeout.seconds=30
export OPENIDM_OPTS="-Xmx4096m -Xms4096m -Didm.shutdown.jetty.timeout.seconds=30"
Jetty thread settings and Gzip compression
To change the Jetty thread pool and Gzip compression settings, make changes to your project’s conf/webserver.json file:
{
"maxThreads": {
"$int": "&{openidm.webserver.max.threads|&{org.ops4j.pax.web.server.maxThreads|200}}"
}
}
Jetty QoSHandler
The Jetty QoSHandler limits the number of threads most PingIDM requests can run on. The handler is configured to use all but two threads to ensure requests to critical endpoints are always handled.
The critical endpoints include:
-
openidm/health/live -
openidm/metrics/*
Learn more about these endpoints at Liveness and readiness probes and in the Metrics reference.
The QoSHandler keeps its own queue of requests rather than allowing requests to queue in the Jetty QueuedThreadPool. Because of this, the jetty.thread.queue (API) and the idm_jetty_thread_queue (Prometheus) metric should remain at 0.The queued requests are handled by the jetty.qos.queue.count API metric and the idm_jetty_qos_queue_count gauge metric in Prometheus.