January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (DROOLS-5969) Rule relationship analysis graph : handling special syntax or usage rules

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5969?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5969: -------------------------------------- Summary: Rule relationship analysis graph : handling special syntax or usage rules (was: Rule relationship analysis graph : handling edge case rules) > Rule relationship analysis graph : handling special syntax or usage rules > ------------------------------------------------------------------------- > > Key: DROOLS-5969 > URL: https://issues.redhat.com/browse/DROOLS-5969 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.49.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5969) Rule relationship analysis graph : handling edge case rules

by Toshiya Kobayashi (Jira)

Toshiya Kobayashi created DROOLS-5969: ----------------------------------------- Summary: Rule relationship analysis graph : handling edge case rules Key: DROOLS-5969 URL: https://issues.redhat.com/browse/DROOLS-5969 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.49.0.Final Reporter: Toshiya Kobayashi Assignee: Toshiya Kobayashi Using real rules, find issues caused by special syntax or usage and fix. Add tests to drools-impact-analysis-itests. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14371) EJB timer not executed on Postgres due to timestamp comparison

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-14371?page=com.atlassian.jira.plugi... ] Chao Wang updated WFLY-14371: ----------------------------- Summary: EJB timer not executed on Postgres due to timestamp comparison (was: [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison) > EJB timer not executed on Postgres due to timestamp comparison > -------------------------------------------------------------- > > Key: WFLY-14371 > URL: https://issues.redhat.com/browse/WFLY-14371 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 22.0.0.Final > Reporter: Chao Wang > Assignee: Cheng Fang > Priority: Major > Labels: support > > A single action timer fails to be executed: > {noformat} > 15:40:25,613 hz0v DEBUG [org.jboss.as.ejb3.timer] (EJB default - 5) Skipping execution of timer for ROOT.ROOT.EJBTimerScheduler as it is being run on another node or the execution is suppressed by configuration > {noformat} > *Environment*: > * RHPAM 7.7.1 > * EAP 7.2.9 > * OCP 3.11 > * single node setup > * DB: PostgreSQL 10.12, JDBC version: 42.2.3 -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14372) Multiple metrics collections

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14372?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-14372: ------------------------------------ Priority: Critical (was: Major) > Multiple metrics collections > ---------------------------- > > Key: WFLY-14372 > URL: https://issues.redhat.com/browse/WFLY-14372 > Project: WildFly > Issue Type: Task > Components: MP Metrics > Reporter: Brian Stansberry > Assignee: Jason Lee > Priority: Critical > > See discussion on https://github.com/wildfly/wildfly/pull/13871 > Do we have MetricsCollector collecting the container metrics multiple times? > I haven't thought hard about this, but doesn't the Stage.VERIFY collection in MetricsSubsystemAdd end up re-collecting all the deployment=* subtree metrics already collected in Stage.RUNTIME via DeploymentMetricProcessor/DeploymentMetricService? It walks the whole resource tree from the root. > If the MP Metrics subsystem is installed, isn't MicroProfileMetricsSubsystemAdd and that subsystem's DeploymentMetricProcessor/DeploymentMetricService also collecting the same set of metrics? > I'm filing this as a Task because maybe all that's needed is to investigate and answer those questions reporting that all is well. But if all isn't well this should converted to a Bug. > Also, as discussed on PR #13871, https://github.com/wildfly/wildfly/blob/22.0.0.Final/metrics/src/main/jav... is probably not the best idiom given the code is iterating over runtime-only resources, where the cost of hasChildren can be high. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14372) Multiple metrics collections

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14372: --------------------------------------- Summary: Multiple metrics collections Key: WFLY-14372 URL: https://issues.redhat.com/browse/WFLY-14372 Project: WildFly Issue Type: Task Components: MP Metrics Reporter: Brian Stansberry Assignee: Jason Lee See discussion on https://github.com/wildfly/wildfly/pull/13871 Do we have MetricsCollector collecting the container metrics multiple times? I haven't thought hard about this, but doesn't the Stage.VERIFY collection in MetricsSubsystemAdd end up re-collecting all the deployment=* subtree metrics already collected in Stage.RUNTIME via DeploymentMetricProcessor/DeploymentMetricService? It walks the whole resource tree from the root. If the MP Metrics subsystem is installed, isn't MicroProfileMetricsSubsystemAdd and that subsystem's DeploymentMetricProcessor/DeploymentMetricService also collecting the same set of metrics? I'm filing this as a Task because maybe all that's needed is to investigate and answer those questions reporting that all is well. But if all isn't well this should converted to a Bug. Also, as discussed on PR #13871, https://github.com/wildfly/wildfly/blob/22.0.0.Final/metrics/src/main/jav... is probably not the best idiom given the code is iterating over runtime-only resources, where the cost of hasChildren can be high. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14371) [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-14371?page=com.atlassian.jira.plugi... ] Chao Wang reassigned WFLY-14371: -------------------------------- Assignee: Cheng Fang (was: Chao Wang) > [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison > --------------------------------------------------------------------------- > > Key: WFLY-14371 > URL: https://issues.redhat.com/browse/WFLY-14371 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 22.0.0.Final > Reporter: Chao Wang > Assignee: Cheng Fang > Priority: Major > Labels: support > > A single action timer fails to be executed: > {noformat} > 15:40:25,613 hz0v DEBUG [org.jboss.as.ejb3.timer] (EJB default - 5) Skipping execution of timer for ROOT.ROOT.EJBTimerScheduler as it is being run on another node or the execution is suppressed by configuration > {noformat} > *Environment*: > * RHPAM 7.7.1 > * EAP 7.2.9 > * OCP 3.11 > * single node setup > * DB: PostgreSQL 10.12, JDBC version: 42.2.3 -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14371) [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFLY-14371?page=com.atlassian.jira.plugi... ] Chao Wang moved JBEAP-20919 to WFLY-14371: ------------------------------------------ Component/s: EJB (was: EJB) Fix Version/s: (was: 7.3.6.GA) Key: WFLY-14371 (was: JBEAP-20919) Affects Version/s: 22.0.0.Final (was: 7.2.9.GA) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Project: WildFly (was: JBoss Enterprise Application Platform) > [GSS](7.3.z) EJB timer not executed on Postgres due to timestamp comparison > --------------------------------------------------------------------------- > > Key: WFLY-14371 > URL: https://issues.redhat.com/browse/WFLY-14371 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 22.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > Labels: support > > A single action timer fails to be executed: > {noformat} > 15:40:25,613 hz0v DEBUG [org.jboss.as.ejb3.timer] (EJB default - 5) Skipping execution of timer for ROOT.ROOT.EJBTimerScheduler as it is being run on another node or the execution is suppressed by configuration > {noformat} > *Environment*: > * RHPAM 7.7.1 > * EAP 7.2.9 > * OCP 3.11 > * single node setup > * DB: PostgreSQL 10.12, JDBC version: 42.2.3 -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5260) (7.3.z) Upgrade jboss-logmanager to 2.1.18.Final

by James Perkins (Jira)

James Perkins created WFCORE-5260: ------------------------------------- Summary: (7.3.z) Upgrade jboss-logmanager to 2.1.18.Final Key: WFCORE-5260 URL: https://issues.redhat.com/browse/WFCORE-5260 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade the {{org.jboss.logmanager:jboss-logmanager}} to 2.1.18.Final -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5259) Upgrade jboss-logmanager to 2.1.18.Final

by James Perkins (Jira)

James Perkins created WFCORE-5259: ------------------------------------- Summary: Upgrade jboss-logmanager to 2.1.18.Final Key: WFCORE-5259 URL: https://issues.redhat.com/browse/WFCORE-5259 Project: WildFly Core Issue Type: Component Upgrade Components: Logging Reporter: James Perkins Assignee: James Perkins Upgrade the {{org.jboss.logmanager:jboss-logmanager}} to 2.1.18.Final -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (LOGMGR-283) The TCCL should be set when configuring resources

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-283?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-283: --------------------------------- Fix Version/s: 2.1.18.Final 2.2.0.Final 2.3.0.Beta1 > The TCCL should be set when configuring resources > ------------------------------------------------- > > Key: LOGMGR-283 > URL: https://issues.redhat.com/browse/LOGMGR-283 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Fix For: 2.1.18.Final, 2.2.0.Final, 2.3.0.Beta1 > > > When configuring resources the TCCL should be set to the class loader for the type being configured. In the case of a modular environment the type may use the TCCL to initialize other types. For example in WildFly if a {{custom-handler}} is used that handler may be in it's own module and attempt to use the TCCL to initialize another type. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2021