[jira] [Resolved] (OAK-9930) Thread leak in elastic index statistics module

["Nuno Santos (Jira)" <ji...@apache.org>]

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

Nuno Santos resolved OAK-9930.
------------------------------
    Fix Version/s: 1.46.0
       Resolution: Done

> Thread leak in elastic index statistics module
> ----------------------------------------------
>
>                 Key: OAK-9930
>                 URL: https://issues.apache.org/jira/browse/OAK-9930
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: indexing
>            Reporter: Nuno Santos
>            Priority: Major
>             Fix For: 1.46.0
>
>
> The method {{ElasticIndexStatistics.CountCacheLoader#reload}} creates a single-threaded executor to perform a query to Elastic in the background. However, it does not properly dispose of the thread pool. Notice that the code does not keep any reference to the executor that it creates, therefore it will never call shutdown to properly dispose of the executor and of the underlying thread. This will lead to an accumulation of unused threads, taking up memory and system resources.    
> {code:java}
> public ListenableFuture<Integer> reload(@NotNull StatsRequestDescriptor crd, @NotNull Integer oldValue) {
>     ListenableFutureTask<Integer> task = ListenableFutureTask.create(() -> count(crd));
>     Executors.newSingleThreadExecutor().execute(task);
>     return task;
> } {code}
> Link to code in Git: [https://github.com/apache/jackrabbit-oak/blob/5b1916dfd69e82759d80aff867d34bad94ea[…]ackrabbit/oak/plugins/index/elastic/ElasticIndexStatistics.java|https://github.com/apache/jackrabbit-oak/blob/5b1916dfd69e82759d80aff867d34bad94eac760/oak-search-elastic/src/main/java/org/apache/jackrabbit/oak/plugins/index/elastic/ElasticIndexStatistics.java#L192-L195]
> In addition to the resource leak, it is not good practice to create a new thread pool to execute a single request. A better alternative is to either use the ForkJoin pool provided by the Java runtime or to create a long-lived thread pool to execute these requests.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)