[rules-dev] ExecutorProvider as a Service

Mario Fusco mario.fusco at gmail.com
Wed Mar 14 13:27:10 EDT 2012


Hi all,

following the suggestions of Mark on how to create a new Service I just
pushed a new one named ExecutorProvider. The idea here is that we should
never manually create and start Threads in the Drools code because this is
inefficient and event worse is not portable in many enterprise
environments. In this way it will be possible to provide different
implementations of this Service that could work with J2EE, Spring or other
similar managed environments.

The ExecutorProvider is defined as it follows:

public interface ExecutorProvider extends Service {
    Executor getExecutor();
    <T> CompletionService<T> getCompletionService();
}

I am already using it to make the jitting compilation of my MvelConstraint
an asynchronous process and also to replace the Threads used in the
KnowledgeAgentImpl and ResourceChangeScannerImpl. For instance in the
KnowledgeAgentImpl I replaced this code:

this.thread = new Thread( this.changeSetNotificationDetector );
this.thread.start();

with this one:

this.notificationDetectorExecutor =

ExecutorProviderFactory.getExecutorProvider().<Boolean>getCompletionService()
                            .submit(this.changeSetNotificationDetector,
true);

where the notificationDetectorExecutor is a Future so I can stop its
execution with:

this.notificationDetectorExecutor.cancel(true);

instead of doing:

this.thread.interrupt();

Also note that, at the moment, the ExecutorService internally used in the
ExecutorProviderImpl (the only ExecutorProvider implementation currently
available) always uses daemon Threads, so the JVM won't be prevented to
terminate if there are some of them still running.

Mario
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120314/bb88c18b/attachment.html 


More information about the rules-dev mailing list