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

[dhannydw]

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.

[alexbudarov]

Hi,
Please take a look at this closed issue: #3097 (comment)
and this: #3183

So you need to:

• update to CUBA 7.2.14 or later (using latest bugfix is always recommended)
• use the cuba.backgroundWorker.minBackgroundThreadsCount property to set pool size.