Thread Pools and Concurrency

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.

 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

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

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

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

Class/Method

default value

minimum value

hints

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

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

AppServer

links

comment

Tomcat

The HTTP Connector

Configure acceptCount and maxThreads values

Undertow

 

 

Jetty