[JBoss JIRA] (WFLY-6322) Module io.undertow.js is marked "unsupported"
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-6322?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-6322:
-----------------------------------
Description:
The WFLY-6049 work brought some module classification changes forward from EAP review work. The changes there to 'private' are fine, but 'unsupported' is an EAP-only classification that doesn't apply upstream. Upstream such a module is public.
WildFly doesn't support any modules in the sense that EAP uses the term.
was:
The WFLY-6049 work brought some module classification changes forward from EAP review work. The changes there to 'private' are fine, but 'unsupported' is an EAP-only classification that doesn't apply upstream. Upstream such a module is public.
WildFly doesn't support any modules in the sense the EAP users the term.
> Module io.undertow.js is marked "unsupported"
> ---------------------------------------------
>
> Key: WFLY-6322
> URL: https://issues.jboss.org/browse/WFLY-6322
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.1.0.Final
>
>
> The WFLY-6049 work brought some module classification changes forward from EAP review work. The changes there to 'private' are fine, but 'unsupported' is an EAP-only classification that doesn't apply upstream. Upstream such a module is public.
> WildFly doesn't support any modules in the sense that EAP uses the term.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6322) Module io.undertow.js is marked "unsupported"
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-6322:
--------------------------------------
Summary: Module io.undertow.js is marked "unsupported"
Key: WFLY-6322
URL: https://issues.jboss.org/browse/WFLY-6322
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 10.1.0.Final
The WFLY-6049 work brought some module classification changes forward from EAP review work. The changes there to 'private' are fine, but 'unsupported' is an EAP-only classification that doesn't apply upstream. Upstream such a module is public.
WildFly doesn't support any modules in the sense the EAP users the term.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6321 at 3/4/16 1:57 PM:
-------------------------------------------------------------------
The tool is based on Byteman. Here are the ingredients:
1. A set of Byteman rules which get triggered when thread pools are created and accessed (in the case of count based monitoring) OR a set of rules which get triggered every 10 seconds (in the case of period based monitoring)
2. a JBoss Modules module called org.wildfly.byteman.rule.helper.threadpool which contains several Byteman helper classes which are made use of by the rules (see https://github.com/rachmatowicz/byteman-threadpool-helper)
3. A SmartFrog job configured to test a custom build, start Byteman with the rule sets on each server and post-process the server logs to extract the thread pool statistics generated and present them in a separate report
The build under test currently needs to have the org.wildfly.byteman.rule.helper.threadpool module added to it in order for the Byteman rules to work. This has to do with reconciling JBoss Modules classloading with the way Byteman works by default (in non-application server contexts).
was (Author: rachmato):
The tool is based on Byteman. Here are the ingredients:
1. A set of Byteman rules which get triggered when thread pools are created and accessed (in the case of count based monitoring) OR a set of rules which get triggered every 10 seconds (in the case of period based monitoring)
2. a JBoss Modules module called org.wildfly.byteman.rule.helper.threadpool which contains several Byteman helper classes which are made use of by the rules (see https://github.com/rachmatowicz/byteman-threadpool-helper)
3. A SmartFrog job configured to test a custom build, start Byteman with the rule sets on each server and post-process the server logs to extract the thread pool statistics generated and present them in a separate report
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6321:
-------------------------------------------
The tool is based on Byteman. Here are the ingredients:
1. A set of Byteman rules which get triggered when thread pools are created and accessed (in the case of count based monitoring) OR a set of rules which get triggered every 10 seconds (in the case of period based monitoring)
2. a JBoss Modules module called org.wildfly.byteman.rule.helper.threadpool which contains several Byteman helper classes which are made use of by the rules (see https://github.com/rachmatowicz/byteman-threadpool-helper)
3. A SmartFrog job configured to test a custom build, start Byteman with the rule sets on each server and post-process the server logs to extract the thread pool statistics generated and present them in a separate report
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-6321:
-------------------------------------------
The thread pools of interest in JGroups:
- created in org.jgroups.protocols.TP
- thread pools:
-- regular
-- OOB
-- internal
The thread pools of interest in Infinispan:
- majority created in org.infinispan.factories.NamedExecutorsFactory
- thread pools:
-- transport
-- remote
-- notification
-- persistence
-- expiration
-- replicationQueue
-- stateTransferExecutor
-- totalOrderExecutor
-- async
-- timeout
There are two approaches to monitoring thread pools used here:
- dump thread pool statistics every X calls to the Executor
- dump thread pool statistics every X seconds
For each thread pool, we present these statistics:
- pool: the number of threads currently available in the pool
- activePool: the number of active threads (i.e. threads which are executing some task)
- queuedTasks: the number of queued tasks waiting for an available thread
- completedTasks: the number of tasks completed by some thread in the thread pool
Rejected execution exceptions are also monitored; these occur when the thread pool is "overwhelmed".
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
Richard Achmatowicz created WFLY-6321:
-----------------------------------------
Summary: Create tool to monitor clustering thread pool usage
Key: WFLY-6321
URL: https://issues.jboss.org/browse/WFLY-6321
Project: WildFly
Issue Type: Task
Components: Clustering
Reporter: Richard Achmatowicz
Assignee: Paul Ferraro
Priority: Minor
Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-6321) Create tool to monitor clustering thread pool usage
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6321?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz reassigned WFLY-6321:
-----------------------------------------
Assignee: Richard Achmatowicz (was: Paul Ferraro)
> Create tool to monitor clustering thread pool usage
> ---------------------------------------------------
>
> Key: WFLY-6321
> URL: https://issues.jboss.org/browse/WFLY-6321
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Minor
>
> Scheduled executors and thread pools are used widely in JGroups and Infinispan for asynchronously executing tasks. When thread pools are not adequately sized to the load they are subjected to, this can lead to performance problems.
> It would be helpful if we could see thread pool usage as a function of elapse time during performance runs, in order to diagnose potential thread pool issues.
> This task will provide a Byteman-based tool to monitor threadpool usage and allow a report to be attached to SmartFrog test jobs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1075) kie-spring component does not execute batch commands
by Samuel Tauil (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1075?page=com.atlassian.jira.plugi... ]
Samuel Tauil commented on DROOLS-1075:
--------------------------------------
Another interesting finding:
1) I got the set-global working, but only when using Stateful session.
2) Need to manually call ksession.fireAllRules on the Stateful session because this doesn't happen automatically.
> kie-spring component does not execute batch commands
> ----------------------------------------------------
>
> Key: DROOLS-1075
> URL: https://issues.jboss.org/browse/DROOLS-1075
> Project: Drools
> Issue Type: Bug
> Components: integration
> Affects Versions: 6.3.0.Final
> Environment: Versions:
> Drools - 6.3.0.Final-redhat-7
> Spring - 4.0.2.RELEASE
> Camel - 2.15.1.redhat-621084
> Reporter: Samuel Tauil
> Assignee: Mario Fusco
> Labels: camel, kie-spring, spring
>
> When defining any type of bean inside the tag kie:batch, seems that nothing gets executed. I added a reference to a bean to be identified by a global variable in a rule and this global always get null.
> this is an example of configuration:
> <kie:batch>
> <kie:set-global identifier="droolsCamelHelper">
> <bean class="com.redhat.gpe.coursecompletion.util.DroolsCamelHelper"/>
> </kie:set-global>
> </kie:batch>
> Also looking to the tests in the kie-spring component source code the list is define in the configurations as follows:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/953263b9f6bf7f9...
> But the rule tests if it's null:
> https://github.com/droolsjbpm/droolsjbpm-integration/blob/953263b9f6bf7f9...
> So this error never raises.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month