[jboss-jira] [JBoss JIRA] (WFLY-12724) Improve batch thread-pool configuration to support thread-pool core-size

[ https://issues.jboss.org/browse/WFLY-12724?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12724: ------------------------------ Description: The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources. current batch subsystem schema snippet: {code:xml} <xs:complexType name="thread-poolType"> <xs:annotation> <xs:documentation> <![CDATA[ A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no upper bound. When a task is submitted, if the number of running threads is less than the core size, a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be submitted to this type of executor, an out of memory condition may occur. The "max-threads" attribute must be used to specify the thread pool size. The nested "keepalive-time" element may used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down. The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker threads. ]]> </xs:documentation> </xs:annotation> <xs:all> <xs:element name="max-threads" type="threads:countType"/> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/> </xs:all> <xs:attribute name="name" use="required" type="xs:string"/> </xs:complexType> {code} Example of batch subsystem in server configuration file: {code:xml} <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0"> <default-job-repository name="in-memory"/> <default-thread-pool name="batch"/> <job-repository name="in-memory"> <in-memory/> </job-repository> <thread-pool name="batch"> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem> {code} Example of batch subsystem management resources: {code} [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource { "outcome" => "success", "result" => { "restart-jobs-on-resume" => true, "security-domain" => undefined, "default-job-repository" => "in-memory", "default-thread-pool" => "batch", "in-memory-job-repository" => {"in-memory" => undefined}, "jdbc-job-repository" => undefined, "thread-factory" => undefined, "thread-pool" => {"batch" => undefined} } } {code} was: The batch subsystem thread-pool currently does not allow to configure its core size. Its core size is always the same as its max size. Upon new task submission, a new thread is created up to the max thread limit, even when there are idle thread available. And pooled threads (core threads) will stay active and will not time out. Need to improve the thead pool configuration to allow for more efficient use of thread resources. current batch subsystem schema snippet: {code:xml} <xs:complexType name="thread-poolType"> <xs:annotation> <xs:documentation> <![CDATA[ A thread pool executor with an unbounded queue. Such a thread pool has a core size and a queue with no upper bound. When a task is submitted, if the number of running threads is less than the core size, a new thread is created. Otherwise, the task is placed in queue. If too many tasks are allowed to be submitted to this type of executor, an out of memory condition may occur. The "max-threads" attribute must be used to specify the thread pool size. The nested "keepalive-time" element may used to specify the amount of time that pool threads should be kept running when idle; if not specified, threads will run until the executor is shut down. The "thread-factory" element specifies the bean name of a specific thread factory to use to create worker threads. ]]> </xs:documentation> </xs:annotation> <xs:all> <xs:element name="max-threads" type="threads:countType"/> <xs:element name="keepalive-time" type="threads:time" minOccurs="0"/> <xs:element name="thread-factory" type="threads:ref" minOccurs="0"/> </xs:all> <xs:attribute name="name" use="required" type="xs:string"/> </xs:complexType> {code} Example of batch subsystem in server configuration file: {code:xml} <subsystem xmlns="urn:jboss:domain:batch-jberet:2.0"> <default-job-repository name="in-memory"/> <default-thread-pool name="batch"/> <job-repository name="in-memory"> <in-memory/> </job-repository> <thread-pool name="batch"> <max-threads count="10"/> <keepalive-time time="30" unit="seconds"/> </thread-pool> </subsystem> {code} Example of batch subsystem management resources: {code} [standalone@localhost:9990 /] /subsystem=batch-jberet:read-resource { "outcome" => "success", "result" => { "restart-jobs-on-resume" => true, "security-domain" => undefined, "default-job-repository" => "in-memory", "default-thread-pool" => "batch", "in-memory-job-repository" => {"in-memory" => undefined}, "jdbc-job-repository" => undefined, "thread-factory" => undefined, "thread-pool" => {"batch" => undefined} } } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)