[JBoss JIRA] (WFCORE-1340) Store "host ignore" data in the domain wide model
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1340?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1340:
-------------------------------------
Description:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
Proposed structure:
Resources are at address /host-ignore=*
Attributes are:
* management-major-version
* management-minor-version
* management-micro-version
* slave-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* active-server-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
was:
Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
Proposed structure:
Resources are at address /host-ignore=*
Attributes are:
* slave-api-major-version
* slave-api-minor-version
* slave-api-micro-version
* slave-release
These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
If slave-api-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
In addition to the above scoping attributes, the following attributes will be supported:
* ignored-extensions
* unignored-server-groups
The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
The unignored-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
Adding a new group to unignored-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
> Store "host ignore" data in the domain wide model
> -------------------------------------------------
>
> Key: WFCORE-1340
> URL: https://issues.jboss.org/browse/WFCORE-1340
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> Including an EAP 6.x slave in a mixed domain managed by a WF 10 / EAP 7 DC is overly difficult operationally because potentially numerous host configurations need to be manually updated whenever new server groups and profiles are added.
> An issue with managing mixed domains is the need for the slave's host.xml to include configuration of what domain-wide content should be ignored. This isn't nice as it requires modifying potentially many host configs when new domain-wide content is added (e.g. new server groups or profiles that the legacy slaves won't understand.)
> Core 2 / Full 10 are better in this regard as they allow "ignore-unused-configuration" where stuff is auto-ignored. But this still has weaknesses:
> 1) The "ignore-unused-configuration" logic is slave-side and is not present in EAP 6.x slaves. So for those slaves manual configuration is the only option.
> 2) Extensions are not covered, so new extensions in later releases may need to be manually configured. (The goal though is to cover this in 11, so this JIRA would just provide a fallback for 11 DCs managing 10 slaves in case that goal is not met. EAP 6 slaves would not benefit from this though.)
> Idea here is to include config for host-ignores in the domain-wide model, for use by the DC. It's in the domain-wide model, not the DC's host.xml, to ensure that any backup HC has the latest data.
> Proposed structure:
> Resources are at address /host-ignore=*
> Attributes are:
> * management-major-version
> * management-minor-version
> * management-micro-version
> * slave-release
> These identify the category of slave to which host-ignore data should be applied when a matching slave registers. The first 3 attributes identify the *core management API version* of the slave (not its release version.) The last is a user-friendly *alternative* to the first 3 and is an enum identifying well known releases (e.g. EAP6.2, EAP6.3, EAP6.4) from which the api versions can be derived.
> If management-micro-version is undefined, the meaning is the config applies to all releases of the given major/minor version, excluding any for which a config with a micro version specified is also present. Not specifying a micro is expected to be the norm. The "slave-release" enums will be for minors.
> In addition to the above scoping attributes, the following attributes will be supported:
> * ignored-extensions
> * active-server-groups
> The ignored-extensions attribute is a list of extension names the resources for which (/extension=X) should be treated as ignored by the target hosts.
> The active-server-groups attribute is a list of server groups names the members of which should be treated as *not* ignored by the target hosts. These are the groups used by the host's servers. The server-group and related profile, socket-binding-group and deployment resources will not be ignored; all others will be ignored. This is the same data that a core 2 / WF 10 slave sends when it registers. This JIRA just provides a different mechanism for making the data known to the DC.
> Adding a new group to active-server-groups will not cause existing slave HCs to get new data sent to them, at least not in the first round of this work. The slave will need to reconnect to get new data.
> There is other data that could be included in these resources, e.g. fine grained "ignore" information matching what can be configured in host.xml, but that is out of scope for this first cut, and may never be added if there is no clear demand.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6090) Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6090:
------------------------------------
Summary: Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final
Key: WFLY-6090
URL: https://issues.jboss.org/browse/WFLY-6090
Project: WildFly
Issue Type: Bug
Components: Clustering
Reporter: Stuart Douglas
Assignee: Paul Ferraro
The upgrade to Undertow 1.3.16.Final causes this test to fail frequently (but not every time).
The change that makes this more frequent was the change to send the response before closing the session. If you are having trouble reproducing this you can add the following code to the bottom of the SessionOperationServlet doGet method to make it 100% reproducible (this should work with any version of Undertow):
{code}
resp.getOutputStream().close();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
{code}
The underlying problem here is the way the passivation/activation listeners are called.
Previously if you did not close the response in the Servlet the session would be closed before the response would be sent, which guaranteed that prePassivate would be called. This also had the side effect that the test would only ever require a single request to see the first session passivating.
This is no longer the case, which means the following:
- Sometimes session1 has not had its passivation listener called before the session2 request is made
- The second session2 request can result in a call to sessionActivated (which makes the test fail). This is especially bogus as there is a chance session2 has not had sessionWillPassivate called yet.
The underlying cause of all this is the way listeners are handled in InfinispanSessionManager when persistent is true. Basically:
- Requests can cause a session to activate before the passivation listener has been called, resulting in out of order invocations
- Multiple concurrent requests to a session will result in multiple activation callbacks, followed by multiple passivation callbacks.
Basically at the moment the ordering these events is completely broken.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5828) Format differences between default configuration and read/persisted one
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5828?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-5828:
---------------------------------
Component/s: EJB
Web (Undertow)
> Format differences between default configuration and read/persisted one
> -----------------------------------------------------------------------
>
> Key: WFLY-5828
> URL: https://issues.jboss.org/browse/WFLY-5828
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Web (Undertow)
> Affects Versions: 10.0.0.CR4
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Labels: ux
>
> Neverending classic, just like every release:
> {noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
> 1c1
> < <?xml version='1.0' encoding='UTF-8'?>
> ---
> > <?xml version="1.0" ?>
> 4d3
> <
> 36,37d34
> <
> <
> 64c61
> < <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
> ---
> > <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
> 87d83
> <
> 178a175
> > <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 182d178
> < <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
> 186a183
> > <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
> 193c190
> < <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
> ---
> > <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
> 220c217
> < <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
> ---
> > <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
> 226c223
> < <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
> ---
> > <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
> 234c231
> < <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
> ---
> > <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
> 242c239
> < <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
> ---
> > <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
> 244,247d240
> < <local-cache name="local-query">
> < <eviction max-entries="10000" strategy="LRU"/>
> < <expiration max-idle="100000"/>
> < </local-cache>
> 250c243
> < <eviction max-entries="10000" strategy="LRU"/>
> ---
> > <eviction strategy="LRU" max-entries="10000"/>
> 252a246,249
> > <local-cache name="local-query">
> > <eviction strategy="LRU" max-entries="10000"/>
> > <expiration max-idle="100000"/>
> > </local-cache>
> 403c400
> < <http-listener name="default" redirect-socket="https" socket-binding="http"/>
> ---
> > <http-listener name="default" socket-binding="http" redirect-socket="https"/>
> 418,419c415,416
> < <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
> < <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
> ---
> > <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> > <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
> 434d430
> <
> 446d441
> <
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6089) Format differences between default configuration and read/persisted one
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6089:
------------------------------------
Summary: Format differences between default configuration and read/persisted one
Key: WFLY-6089
URL: https://issues.jboss.org/browse/WFLY-6089
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Neverending classic, just like every release:
{noformat}[rhusar@syrah wildfly-10.0.0.Final-SNAPSHOT]$ diff standalone/configuration/standalone-ha.xml standalone/configuration/standalone_xml_history/standalone-ha.initial.xml
1c1
< <?xml version='1.0' encoding='UTF-8'?>
---
> <?xml version="1.0" ?>
4d3
<
36,37d34
<
<
64c61
< <file-handler name="file" formatter="json-formatter" path="audit-log.log" relative-to="jboss.server.data.dir"/>
---
> <file-handler name="file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
87d83
<
178a175
> <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
182d178
< <stateful default-access-timeout="5000" cache-ref="distributable" passivation-disabled-cache-ref="simple"/>
186a183
> <!-- Automatically configure pools. Alternatively, max-pool-size can be set to a specific value -->
193c190
< <cache name="distributable" passivation-store-ref="infinispan" aliases="passivating clustered"/>
---
> <cache name="distributable" aliases="passivating clustered" passivation-store-ref="infinispan"/>
220c217
< <cache-container name="server" aliases="singleton cluster" module="org.wildfly.clustering.server" default-cache="default">
---
> <cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
226c223
< <cache-container name="web" module="org.wildfly.clustering.web.infinispan" default-cache="dist">
---
> <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
234c231
< <cache-container name="ejb" aliases="sfsb" module="org.wildfly.clustering.ejb.infinispan" default-cache="dist">
---
> <cache-container name="ejb" aliases="sfsb" default-cache="dist" module="org.wildfly.clustering.ejb.infinispan">
242c239
< <cache-container name="hibernate" module="org.hibernate.infinispan" default-cache="local-query">
---
> <cache-container name="hibernate" default-cache="local-query" module="org.hibernate.infinispan">
244,247d240
< <local-cache name="local-query">
< <eviction max-entries="10000" strategy="LRU"/>
< <expiration max-idle="100000"/>
< </local-cache>
250c243
< <eviction max-entries="10000" strategy="LRU"/>
---
> <eviction strategy="LRU" max-entries="10000"/>
252a246,249
> <local-cache name="local-query">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration max-idle="100000"/>
> </local-cache>
403c400
< <http-listener name="default" redirect-socket="https" socket-binding="http"/>
---
> <http-listener name="default" socket-binding="http" redirect-socket="https"/>
418,419c415,416
< <response-header name="server-header" header-value="WildFly/10" header-name="Server"/>
< <response-header name="x-powered-by-header" header-value="Undertow/1" header-name="X-Powered-By"/>
---
> <response-header name="server-header" header-name="Server" header-value="WildFly/10"/>
> <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
434d430
<
446d441
<
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1341) Remoting worker threads runtime current size, queue size, etc are not visible
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1341?page=com.atlassian.jira.plugi... ]
Brad Maxwell commented on WFCORE-1341:
--------------------------------------
[~ctomc] , should the runtime data be shown via?
{code}
/subsystem=io:read-resource(include-runtime=true, recursive=true)
{
"outcome" => "success",
"result" => {
"buffer-pool" => {"default" => {
"buffer-size" => undefined,
"buffers-per-slice" => undefined,
"direct-buffers" => undefined
}},
"worker" => {"default" => {
"io-threads" => undefined,
"stack-size" => 0L,
"task-keepalive" => 60,
"task-max-threads" => undefined
{code}
> Remoting worker threads runtime current size, queue size, etc are not visible
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1341
> URL: https://issues.jboss.org/browse/WFCORE-1341
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Tomaz Cerar
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6088) Remoting worker threads runtime current size, queue size, etc are not visible
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6088?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar reassigned WFLY-6088:
---------------------------------
Assignee: Tomaz Cerar (was: David Lloyd)
> Remoting worker threads runtime current size, queue size, etc are not visible
> -----------------------------------------------------------------------------
>
> Key: WFLY-6088
> URL: https://issues.jboss.org/browse/WFLY-6088
> Project: WildFly
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Tomaz Cerar
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1341) Remoting worker threads runtime current size, queue size, etc are not visible
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1341?page=com.atlassian.jira.plugi... ]
Tomaz Cerar moved WFLY-6088 to WFCORE-1341:
-------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1341 (was: WFLY-6088)
Component/s: Remoting
(was: Remoting)
Affects Version/s: 2.0.7.Final
(was: 10.0.0.CR5)
> Remoting worker threads runtime current size, queue size, etc are not visible
> -----------------------------------------------------------------------------
>
> Key: WFCORE-1341
> URL: https://issues.jboss.org/browse/WFCORE-1341
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 2.0.7.Final
> Reporter: Brad Maxwell
> Assignee: Tomaz Cerar
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6088) Remoting worker threads runtime current size, queue size, etc are not visible
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6088?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-6088:
-----------------------------------
worker-thread-pool configuration and mgmt operations are all deprecated.
only real thing that is supported now is <endpoint worker="worker-reference-to-io-subsystem" />
on which you can get the runtime data.
also worker-thread-pool if configured only proxies configuration to io subsystem.
> Remoting worker threads runtime current size, queue size, etc are not visible
> -----------------------------------------------------------------------------
>
> Key: WFLY-6088
> URL: https://issues.jboss.org/browse/WFLY-6088
> Project: WildFly
> Issue Type: Enhancement
> Components: Remoting
> Affects Versions: 10.0.0.CR5
> Reporter: Brad Maxwell
> Assignee: David Lloyd
>
> The remoting subsystem uses a worker-thread-pool which can be configured such as shown below.
> The runtime thread pool information is not exposed when doing read-resource:
> {code}
> /subsystem=remoting:read-resource(include-runtime=true, recursive=true)
> {code}
> {code}
> <subsystem xmlns="urn:jboss:domain:remoting:1.1">
> <worker-thread-pool
> read-threads="1"
> task-core-threads="4"
> task-keepalive="60"
> task-limit="16384"
> task-max-threads="16"
> write-threads="1"
> />
> <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
> </subsystem>
> {code}
> In tuning and runtime diagnosis, it would be useful to see the thread pool information such as the current size, queue-size, largest-thread-count, etc similar to the ejb3 subsystem thread pool:
> {code}
> /subsystem=ejb3/thread-pool=default:read-resource(include-runtime=true, recursive=true)
> "result" => {
> "active-count" => 0,
> "completed-task-count" => 0L,
> "current-thread-count" => 0,
> "keepalive-time" => {
> "time" => 100L,
> "unit" => "MILLISECONDS"
> },
> "largest-thread-count" => 0,
> "max-threads" => 10,
> "name" => "default",
> "queue-size" => 0,
> "rejected-count" => 0,
> "task-count" => 0L,
> "thread-factory" => undefined
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months