On 16 January 2017 at 16:30, Greg Sheremeta <gshereme@redhat.com> wrote:


On Mon, Jan 16, 2017 at 4:45 AM, Roy Golan <rgolan@redhat.com> wrote:
Java EE 7 included ManageExecutorService in its spec. Using Wildfly (as certified EE 7 container) we can use it to replace our own ThreadPoolUtil implementation and (possibly) Quarz usage.

Managed executor service is a thread pool resource, manage by the container and can be controlled via JMX or the startup ovirt-egine.xml.in facility. This means that it could be tweaked at runtime as well. The service has configured thread factory and queue as well, all described by the xml

In the engine we are using mutli pools, with little to no capabilities of tweaking them
- ThreadPoolUtil - our general threading facade
- SchedulerThreadPool - the pool we create to pass to quarz
- HostUpdatesCheckerService.java - internal pool
- CommandExecutor - coco's pool

EE gave us a standard way to handle threads, with runtime configuration and ability to @inject it into the code, this means once again less code with using something the platform already supplies with real tuninig abilities. I know #infra has an item quarts, this should be considered as well.

Following this thread, if there is no suitable bug already, I'll open one for this.


https://bugzilla.redhat.com/show_bug.cgi?id=1416141


+1.

We started using this for the dashboard in a recent patch [3] by Scott:

@Resource
private ManagedScheduledExecutorService scheduledExecutor;



I used it here for POC [1] (in monitoring) and it works well. Just like quartz it support scheduling with a delay or with fixed rate and `ScheduledFuture` supports cancelling.
The only functionality that is missing if we want to replace also gluster usage is db store for triggers. I'm not why db store is need and I'd be happy if one of gluster members would be able to explain the need
  

@Eldad regarding performance, it is not more perfomant as is(in the end quarz it thread pool). It will help us to manage resources better and that may hopefully prevent us from doing stuff wrong. (at least)

[1] https://gerrit.ovirt.org/#/c/70710/1
 

Some code snippets:  
@Resource
private ManagedExecutorService mes;
...  Future f = mes.submit(() -> doThis())

The configuration in ovirt-engine.xml.in (already there today!):

Yep, added by [3] above :)

+1 didn't run git-blame this time :) . 
 


<managed-executor-services>
  <managed-executor-service
  name="default"
  jndi-name="java:jboss/ee/concurrency/executor/default"
  context-service="default"
  thread-factory="default"
  hung-task-threshold="60000"
  core-threads="5"
  max-threads="25"
  keepalive-time="5000"
  queue-length="1000000"
  reject-policy="RETRY_ABORT" />
</managed-executor-services>

Please head here for wildfly docs [1] and here [2] to see a simple example (from one of the members of the EG of EE, recommended blog in general)

[1] https://docs.jboss.org/author/display/WFLY8/EE+Concurrency+Utilities+Configuration
[2] http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_with_java




_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Greg Sheremeta, MBA
Red Hat, Inc.
Sr. Software Engineer
gshereme@redhat.com