| Inhalt |
|---|
General
Internally jadice is making use of ThreadPoolExecutors. The different jadice products give the integrator the possibility to adjust threading by configuring the core pool size and the max pool size of their respective ThreadPoolExecutors.
Before changing the values below make sure you fully understand the consequences
Docker, Kubernetes & OpenShift
By default, most of the initial values for thread pools in jadice are defined by the number of available processors. Unfortunately, in a docker Docker-based environment the Java Runtime may return an unreliable value (see e.g. here) like "1". In that case the minimum value of "2" would be applied, which may be not what you want or expect. It is also possible that other modules or libraries rely on that mechanism which may also lead to an unexpected behavior.
- Docker: set a CPU limit as stated here
- OpenShift: define a Quota for the pod as stated here
- General: you can also set the values for jadice thread pools manually but we recommend setting a CPU-limit on container-level to get a more predictable behavior
-XX:ActiveProcessorCount=Xas JVM option as stated here
jadice document platform
Jadice TaskService Threadpool ("Jadice TaskService Worker default-...")
...
By design, while starting the web-app, your application will most likely make use of a class that extends WebtoolkitServletContextListener (as described here). In this step of the startup-process JWT will for example initialize the DocumentService which already accesses the ServerConfiguration and initializes a thread pool. As a result, your configuration of the thread pools has to take place before this initialization is done. One way to do so is to create a class that extends ServletContextListener and configure it in web.xml above the class that extends WebtoolkitServletContextListener. As per JSR 315 (Servlet 3.0 Specification, Chapter 8.2.3) the ServletContextListeners are executed in the order in which they have been declared in web.xml.
...
Configuration was introduced in 10/2020 with JWT-3436. Details can be found in the JWT documentation.
| Class/Method | default value | minimum value | hints |
|---|---|---|---|
| ServerConfiguration.setGeneralPoolCoreSize | 10 | 0 | |
| ServerConfiguration.setGeneralPoolMaxSize | 50 | 1 & greater than generalPoolCoreSize |
...
| Class/Method | default value | minimum value | hints |
|---|---|---|---|
| ServerConfiguration.setTileRendererPoolCoreSize | Runtime.getRuntime().availableProcessors() or minimum 2 | 0 | |
| ServerConfiguration.setTileRendererPoolMaxSize | Runtime.getRuntime().availableProcessors() or minimum 2 | 1 & greater than tileRendererPoolCoreSize |
Limitations
With JWT-3487 there was a logic introduced, that ensures that a single client can't utilize all tile-rendering threads. This makes sure that a very complex document won't block the work of all other users.
| Class/Method | default value | minimum value | hints |
|---|---|---|---|
| ServerConfiguration.setTileRendererMaxParallelRenderingPerClient |
| 0 | The value 0 means that the behavior is turned off (so a single client can utilize all threads) |
HTTP Request Processing Threads (App-server specific)
...