Thread pools and ManageExecutorService
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. Some code snippets: @Resource private ManagedExecutorService mes; ... Future f = mes.submit(() -> doThis()) The configuration in ovirt-engine.xml.in (already there today!): <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+Configu... [2] http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_wit...
On Mon, Jan 16, 2017 at 10: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
We use 2 pools for quartz with the same implementation
- HostUpdatesCheckerService.java - internal pool - CommandExecutor - coco's pool
There is one more pool use for vdsm event processing: - ForkJoinPool - created with async mode set
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.
I like the idea to managed pool provided by the container but we should revised our way of using threads first before we will take any decisions.
Following this thread, if there is no suitable bug already, I'll open one for this.
Some code snippets:
@Resource private ManagedExecutorService mes;
... Future f = mes.submit(() -> doThis())
The configuration in ovirt-engine.xml.in (already there today!):
<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+Configu... [2] http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_wit...
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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.
+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/...
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 :)
<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
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;
[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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Greg Sheremeta, MBA Red Hat, Inc. Sr. Software Engineer gshereme@redhat.com
+1 Sounds very effective. And this is one of strongest points of jboss. Im very curious to see the engine performance of it. Regards, -Eldad On 16 בינו׳ 2017, at 11:46, 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. Some code snippets: @Resource private ManagedExecutorService mes; ... Future f = mes.submit(() -> doThis()) The configuration in ovirt-engine.xml.in (already there today!): <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+Configu... [2] http://www.adam-bien.com/roller/abien/entry/injecting_an_executorservice_wit... _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (4)
-
Eldad Marciano -
Greg Sheremeta -
Piotr Kliczewski -
Roy Golan