3

We are using Drools 6.3.0Final in a JavaEE 7 application on Weblogic 12.2.1. When our application is initially deployed we see 8 Threads named "drools-worker-X" where X ranges from 1 to 8 (on a 4-core CPU with HT). Now when we redeploy the application the 8 threads remain in state "Park" and 8 new Threads are created (again numbered from 1 to 8). This continues on every redeployment.

As we found out the class ExecutorProviderImpl in package org.drools.core.concurrent creates a new ThreadPoolExecutor with a corePoolSize and maxPoolSize both set to the number of CPU cores and the Timeout to 60s. Once we redeployed a certain number of times the JVM gets slow and our application is no longer running properly.

Is there any way to properly shut down those worker threads when our application shuts down?

phivo
  • 183
  • 2
  • 16
  • You'll catch more fish if you change the title of your question to tell folks what you're asking about. I can only guess 'cause I don't know EE or drools, but I'm thinking something like "How to redeploy drools application in..." or "how to safely use ExecutorProviderImpl in an application that..." " – Solomon Slow May 02 '16 at 15:13
  • If you get ThreadPoolExecutor, you can shutdown in this way: http://stackoverflow.com/questions/36644043/how-to-forcefully-shutdown-java-executorservice/36644320#36644320 – Ravindra babu May 02 '16 at 16:25
  • As Drools is third party and not our own piece of software we have limited influence in changing how Threads are created and shutdown. The question was more towards the Drools guys if their software can be safely used in a Java EE 7 environment. What we've experienced so far is that it's not. – phivo May 03 '16 at 06:14
  • What I've experienced so far is that Drools can be safely used in a Java EE (v7) environment. Are you disposing all resources on un-deployment of your Java EE app? – tarilabs May 03 '16 at 07:08
  • tarilabs. That might be the issue. We are using stateless KieSessions which should implicitly call the dispose() Method so we don't really know what else we can do to properly clean up our resources. Our focus is currently on the ThreadPoolExecutor which runs outside the EE containers and is not managed by them. – phivo May 03 '16 at 08:59
  • 1
    A bug was opened at Jboss for this issue: https://issues.jboss.org/browse/DROOLS-1156 – phivo May 03 '16 at 10:33
  • And the bug seems to be fixed: https://github.com/droolsjbpm/drools/commit/8b268713ab5d8d912e4db039721b25b84945a6ce – phivo May 17 '16 at 19:13

1 Answers1

3

You could implement a Startup-EJB that shuts down the ExecutorService in a @PreDestroy-annotated method. I just tested it in our own project, and it seems to work like a charm.

import java.util.concurrent.ExecutorService;
import org.kie.internal.concurrent.ExecutorProviderFactory;
...

@Startup
@Singleton
public class PlausiServiceLifecycleManager {

    /**
     * Shuts down Drools' internal ExecutorService, so that its threads can terminate.
     */
    @PreDestroy
    public void shutdown() {
        ExecutorService executor = (ExecutorService) ExecutorProviderFactory.getExecutorProvider().getExecutor();
        executor.shutdown();
    }


}
sryll
  • 114
  • 8
  • Just tried your code with our application and it seems to work. When before after each redeploy the number of drools-worker Threads increased by 8 it is now stable at 8 Threads after redeployment. Amazing! Thanks a lot! – phivo Sep 14 '16 at 13:56