Thread Pools and Concurrency
General
Internally jadice is making use of ThreadPoolExecutor
s. 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 ThreadPoolExecutor
s.
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-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=X
as JVM option as stated here
jadice document platform
Jadice TaskService Threadpool ("Jadice TaskService Worker default-...")
Utilization
The workers in this thread pool are used for several tasks within the document platform. Among other aspects some of those tasks are:
- asynchronous reading of different document formats
- text search
- page display in jadice viewer
Configuration
Configuration will be introduced with DOCPV-3299
Property-key | default value | minimum value | hints |
---|---|---|---|
Runtime.getRuntime().availableProcessors() or minimum 2 | 2 | ||
Runtime.getRuntime().availableProcessors() or minimum 2 | 2 |
jadice web toolkit
Be aware that jadice web toolkit is making use of jadice document platform so the above settings have to be considered as well when you customize jadice web toolkit.
Limitations
Configuration of the thread pools take place via the ServerConfiguration
class.
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.
In Spring Boot Environments this configuration can take place in the Spring Boot configuration, e.g. the application.yml.
JadiceWebToolkit General Threadpool ("JadiceWebToolkit General Worker-...")
Utilization
The workers in these thread pool are used for several tasks within jadice web toolkit. Among other things some of those tasks are:
- Asynchronous document loading (DocumentService)
Configuration
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 |
JadiceWebToolkit TileRenderer Threadpool ("JadiceWebToolkit TileRenderer Worker-...")
Utilization
As tile requests are processed asynchronously on the server-side, a thread pool is used to control the render tasks. Note that rendering a tile implies that the document is fetched first which leads to a read process that is handled by jadice document platform and its proprietary thread pools.
Configuration
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.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)
The configuration of the threads that accept http requests is individually handled by the application servers. As jadice web toolkit has no direct possibility to configure this behavior, this section is therefore only a collection of useful hints and links.
AppServer | links | comment |
---|---|---|
Tomcat | The HTTP Connector | Configure acceptCount and values |
Undertow | ||
Jetty |