Thread Pools and Concurrency

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.

(Warnung) 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-keydefault valueminimum valuehints

Runtime.getRuntime().availableProcessors() or minimum 22

Runtime.getRuntime().availableProcessors() or minimum 22

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/Methoddefault valueminimum valuehints
ServerConfiguration.setGeneralPoolCoreSize100
ServerConfiguration.setGeneralPoolMaxSize501 & 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/Methoddefault valueminimum valuehints
ServerConfiguration.setTileRendererPoolCoreSizeRuntime.getRuntime().availableProcessors() or minimum 20
ServerConfiguration.setTileRendererPoolMaxSizeRuntime.getRuntime().availableProcessors() or minimum 21 & 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/Methoddefault valueminimum valuehints
ServerConfiguration.setTileRendererMaxParallelRenderingPerClient
  • if tileRendererPoolMaxSize is bigger than 8
    • tileRendererPoolMaxSize - 2
  • if tileRendererPoolMaxSize is smaller or equal to 8
    • tileRendererPoolMaxSize - 1
  • if tileRendererPoolMaxSize is smaller or equal to 2
    • 0
0The 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.

AppServerlinkscomment
TomcatThe HTTP ConnectorConfigure acceptCount and maxThreads values
Undertow

Jetty