[rules-dev] ExecutorProvider as a Service

[Mark Proctor]

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 <mario.fusco at gmail.com 
> <mailto:mario.fusco at gmail.com>> 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
>     rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
>     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
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev

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