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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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 On Wed, Mar 14, 2012 at 5:27 PM, Mario Fusco <mario.fusco(a)gmail.com&gt;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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev