On 14/03/2012 17:34, Mauricio Salatino wrote:
Oh that looks like a cool way to standardize how all the threads
inside drools are being created.
Do you have already identified where this new approach must be
applied? The rule times are also implementing this approach?
Cheers
Just a reminder to people to re-read this email "api's, factories and
services ":
http://drools.46999.n3.nabble.com/api-s-factories-and-services-td3790118.html
So we can start to standardise how our factories and services work, so
we get the best of our container interoprability - like spring, osgi etc.
Mark
On Wed, Mar 14, 2012 at 5:27 PM, Mario Fusco <[email protected]
<mailto:[email protected]>> wrote:
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
_______________________________________________
rules-dev mailing list
[email protected] <mailto:[email protected]>
https://lists.jboss.org/mailman/listinfo/rules-dev
--
- MyJourney @ http://salaboy.wordpress.com
- Co-Founder @ http://www.jugargentina.org
- Co-Founder @ http://www.jbug.com.ar
- Salatino "Salaboy" Mauricio -
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-dev
