[ 
https://issues.apache.org/jira/browse/UIMA-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Richard Eckart de Castilho updated UIMA-6412:
---------------------------------------------
    Description: 
The {{CPMEngine}} internally uses a {{ThreadGroup}} to manage the worker 
threads. This causes a problem with concurrency features present in modern Java 
versions, e.g. the static system-wide {{ForkJoinPool.commonPool()}} which is 
used by concurrency features by default when no other pool is specified. But 
even if a custom pool is used, the problem persists. The problem is that 
threads launched from within the context of a thread that is part of a thread 
group inherits that thread group as its parent. Consequently, worker threads 
launched e.g. by the {{ForkJoinPool.commonPool()}} become part of the CPM 
thread group. The common pool worker threads are long-lived and re-used. the 
CPM thread group however refuses to shut down as long as there are still 
threads in it. That essentially blocks the use of many concurrency features 
within the scope of a CPE.

The best approach would probably be to replace the {{CPMThreadGroup}} with some 
kind of {{CPMExecutorService}} which essentially performs the same duties as 
the thread group but without being a thread group.

* {{CPMThreadGroup.uncaughtException()}} - instead of handling the uncaught 
exceptions at the level of the thread group, an exception handler needs to be 
installed in the individual spawned threads
* ...

> Stop using ThreadGroup in CPMEngine
> -----------------------------------
>
>                 Key: UIMA-6412
>                 URL: https://issues.apache.org/jira/browse/UIMA-6412
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Collection Processing
>            Reporter: Richard Eckart de Castilho
>            Assignee: Richard Eckart de Castilho
>            Priority: Major
>             Fix For: 3.3.0SDK
>
>
> The {{CPMEngine}} internally uses a {{ThreadGroup}} to manage the worker 
> threads. This causes a problem with concurrency features present in modern 
> Java versions, e.g. the static system-wide {{ForkJoinPool.commonPool()}} 
> which is used by concurrency features by default when no other pool is 
> specified. But even if a custom pool is used, the problem persists. The 
> problem is that threads launched from within the context of a thread that is 
> part of a thread group inherits that thread group as its parent. 
> Consequently, worker threads launched e.g. by the 
> {{ForkJoinPool.commonPool()}} become part of the CPM thread group. The common 
> pool worker threads are long-lived and re-used. the CPM thread group however 
> refuses to shut down as long as there are still threads in it. That 
> essentially blocks the use of many concurrency features within the scope of a 
> CPE.
> The best approach would probably be to replace the {{CPMThreadGroup}} with 
> some kind of {{CPMExecutorService}} which essentially performs the same 
> duties as the thread group but without being a thread group.
> * {{CPMThreadGroup.uncaughtException()}} - instead of handling the uncaught 
> exceptions at the level of the thread group, an exception handler needs to be 
> installed in the individual spawned threads
> * ...



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to