[ovirt-devel] Thread pools and ManageExecutorService

[Roy Golan]

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

>
>
> On Mon, Jan 16, 2017 at 4:45 AM, Roy Golan <rgolan at 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;
>
> [3] https://gerrit.ovirt.org/#/c/67709/7/frontend/webadmin/
> modules/frontend/src/main/java/org/ovirt/engine/ui/
> frontend/server/dashboard/DashboardDataServlet.java
>
>
> 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+U
>> tilities+Configuration
>> [2] http://www.adam-bien.com/roller/abien/entry/injecting_an_
>> executorservice_with_java
>>
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
>
> --
> Greg Sheremeta, MBA
> Red Hat, Inc.
> Sr. Software Engineer
> gshereme at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170124/7e13be0f/attachment-0001.html>