Uploaded image for project: 'Drools'
  1. Drools
  2. DROOLS-1156

drools-worker threads are created but not cleaned up

XMLWordPrintable

    • Hide

      Could be reproduced as well in Tomcat 7, Wildfly 10.0 as in Weblogic 12.2.1:

      1.) Deploy KIE Execution Server
      2.) Create a new KIE container via REST API
      3.) Monitor threads with VisualVM -> having 9 threads called drools-worker-1, drools-worker-2, etc. on a 8-core machine
      4.) Delete KIE container with REST API
      5.) Undeploy application KIE execution server
      6.) Monitor threads with VisualVM -> still 9 threads are around

      If these steps are repeated, the new threads are added each time to the JVM. These leads to a memory leak after some time, as every time you redeploy the application it will create the new threads.

      Show
      Could be reproduced as well in Tomcat 7, Wildfly 10.0 as in Weblogic 12.2.1: 1.) Deploy KIE Execution Server 2.) Create a new KIE container via REST API 3.) Monitor threads with VisualVM -> having 9 threads called drools-worker-1, drools-worker-2, etc. on a 8-core machine 4.) Delete KIE container with REST API 5.) Undeploy application KIE execution server 6.) Monitor threads with VisualVM -> still 9 threads are around If these steps are repeated, the new threads are added each time to the JVM. These leads to a memory leak after some time, as every time you redeploy the application it will create the new threads.
    • NEW
    • NEW

      There is an issue with creation of threads in drools, when using drools in a container (Web Container oder Java EE application server) environment.

      This could be reproduce as well in KIE execution server as in a dummy web application.

      If you create a container in drools, there are several new threads named "drools-worker" created. The number of threads depends on the number of CPU cores.

      When disposing the container, these threads are still running. Even when we undeploy the application, these threads are still running, as they are created by threadpoolexecutor and not by any managedexecutorservice.

              mfusco@redhat.com Mario Fusco
              pieperch C R (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: