We should be allowed to configure Background Worker's queue capacity

Environment

Platform version: 7.2.7 (but seems to happen also in 7.2.15
Operating system: Windows (but seems to happen also on Linux)
JRE: jdk1.8.0_241
Tomcat: Apache Tomcat Version 9.0.27

Description of the enhancement

BackgroundWorker configuration should allow configuration of queueCapacity. This is due to the way ThreadPoolExecutor works, which will only create new thread beyond corePoolSize if the queue is full. Therefore, we should be allowed to tune the ThreadPoolExecutor by also adjusting queueCapacity, in addition to corePoolSize (cuba.backgroundWorker.minBackgroundThreadsCount) and maxPoolSize (webConfig.getMaxActiveBackgroundTasksCount()). Otherwise, maxPoolSize is pretty much useless with unlimited LinkedBlockingQueue.

Use default CUBA properties for backgroundWorker (unchanged):

cuba.backgroundWorker.maxActiveTasksCount=100
cuba.backgroundWorker.minBackgroundThreadsCount=4  #this is undocumented, but implemented as such in com.haulmont.cuba.web.WebConfig

Use a for loop to simulate 100 BackgroundTask and execute each task immediately

for (int z = 0; z < 100; z++) {
  int finalZ = z;
  backgroundWorker.handle(new BackgroundTask<Object, Object>(5, this) {
    @Override
    public Object run(TaskLifeCycle<Object> taskLifeCycle) throws Exception {
      logger.debug("BG #{} start", finalZ);
      Thread.sleep(1500);
      logger.debug("BG #{} end", finalZ);
      return null;
    }
  }).execute();
}

The log shows that only 4 Threads can be active at maximum. Only after any of the active Threads are available, the next task can be started, e.g. BG 5 was blocked when the first 4 Threads are still active.

11:22:31.799 DEBUG BookBrowse       - BG #2 start
11:22:31.799 DEBUG BookBrowse       - BG #1 start
11:22:31.799 DEBUG BookBrowse       - BG #0 start
11:22:31.799 DEBUG BookBrowse       - BG #3 start
11:22:33.305 DEBUG BookBrowse       - BG #1 end
11:22:33.305 DEBUG BookBrowse       - BG #3 end
11:22:33.305 DEBUG BookBrowse       - BG #2 end
11:22:33.305 DEBUG BookBrowse       - BG #0 end
11:22:33.307 DEBUG BookBrowse       - BG #5 start
11:22:33.307 DEBUG WebBackgroundWorker    - Done task. User: admin
11:22:33.307 DEBUG BookBrowse       - BG #6 start
11:22:33.307 DEBUG BookBrowse       - BG #4 start
11:22:33.307 DEBUG WebBackgroundWorker    - Done task. User: admin
11:22:33.308 DEBUG WebBackgroundWorker    - Done task. User: admin
11:22:33.308 DEBUG WebBackgroundWorker    - Done task. User: admin
11:22:33.308 DEBUG BookBrowse       - BG #7 start
11:22:34.821 DEBUG BookBrowse       - BG #5 end
11:22:34.821 DEBUG BookBrowse       - BG #7 end
11:22:34.821 DEBUG BookBrowse       - BG #4 end
11:22:34.821 DEBUG BookBrowse       - BG #6 end
...

Expected behavior

We should be able to specify a property in application.properties to control the backgroundworker's queue capacity. This way, one can tune the ThreadPoolExecutor to increase number of Thread up to maxPoolSize when the queue is full. Note that in general, we want to keep corePoolSize low when the load is low, but can increase when the load is high. But this is not how the corePoolSize and maxPoolSize work.

Actual behavior

We cannot control backgroundworker's queue capacity, and the current implementation uses new LinkedBlockingQueue<>() to create Integer.MAX_VALUE queue capacity. Therefore, the maximum active Thread is always at 4 (default cuba.backgroundWorker.minBackgroundThreadsCount), and never increases because the queue capacity is very large.

cuba-platform / cuba