December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4876) GDST: Aliases only work for Strings

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4876?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4876: --------------------------------- Tester: Jozef Marko Story Points: 3 Labels: drools-tools (was: ) > GDST: Aliases only work for Strings > ----------------------------------- > > Key: DROOLS-4876 > URL: https://issues.redhat.com/browse/DROOLS-4876 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > > If you use the Column creator and add an alias for any other column type than String, the aliases do not show up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4777) Upgrade JBoss Remoting from 5.0.16 to 5.0.17

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFCORE-4777?page=com.atlassian.jira.plug... ] Ilia Vassilev moved JBEAP-18353 to WFCORE-4777: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4777 (was: JBEAP-18353) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Build System (was: Build System) Affects Version/s: (was: 7.2.5.GA) Fix Version/s: (was: 7.3.1.GA) > Upgrade JBoss Remoting from 5.0.16 to 5.0.17 > -------------------------------------------- > > Key: WFCORE-4777 > URL: https://issues.redhat.com/browse/WFCORE-4777 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4876) GDST: Aliases only work for Strings

by Toni Rikkola (Jira)

[ https://issues.redhat.com/browse/DROOLS-4876?page=com.atlassian.jira.plug... ] Toni Rikkola updated DROOLS-4876: --------------------------------- Description: If you use the Column creator and add an alias for any other column type than String, the aliases do not show up. > GDST: Aliases only work for Strings > ----------------------------------- > > Key: DROOLS-4876 > URL: https://issues.redhat.com/browse/DROOLS-4876 > Project: Drools > Issue Type: Bug > Components: Guided Rule Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > > If you use the Column creator and add an alias for any other column type than String, the aliases do not show up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4876) GDST: Aliases only work for Strings

by Toni Rikkola (Jira)

Toni Rikkola created DROOLS-4876: ------------------------------------ Summary: GDST: Aliases only work for Strings Key: DROOLS-4876 URL: https://issues.redhat.com/browse/DROOLS-4876 Project: Drools Issue Type: Bug Components: Guided Rule Editor Reporter: Toni Rikkola Assignee: Toni Rikkola -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4775) Some .CLI commands that has been working since WF9 fails on WF18

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4775?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4775: ---------------------------------- Priority: Critical (was: Blocker) > Some .CLI commands that has been working since WF9 fails on WF18 > ---------------------------------------------------------------- > > Key: WFCORE-4775 > URL: https://issues.redhat.com/browse/WFCORE-4775 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 11.0.0.Beta4 > Reporter: Peter Jonsson > Assignee: Yeray Borges > Priority: Critical > > Error message is > ERROR [org.jboss.as.cli.CommandContext] (CLI command) { > "outcome" => "failed", > "failure-description" => "java.lang.StackOverflowError:null" > } > And in the log > 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{ > "address" => [("subsystem" => "undertow")], > "operation" => "write-attribute", > "name" => "statistics-enabled", > "value" => true, > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > } > }]: java.lang.StackOverflowError > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4775) Some .CLI commands that has been working since WF9 fails on WF18

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4775?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4775: ---------------------------------- Priority: Blocker (was: Major) > Some .CLI commands that has been working since WF9 fails on WF18 > ---------------------------------------------------------------- > > Key: WFCORE-4775 > URL: https://issues.redhat.com/browse/WFCORE-4775 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 11.0.0.Beta4 > Reporter: Peter Jonsson > Assignee: Yeray Borges > Priority: Blocker > > Error message is > ERROR [org.jboss.as.cli.CommandContext] (CLI command) { > "outcome" => "failed", > "failure-description" => "java.lang.StackOverflowError:null" > } > And in the log > 2019-10-21 19:14:44,377 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0403: Unexpected failure during execution of the following operation(s): [{ > "address" => [("subsystem" => "undertow")], > "operation" => "write-attribute", > "name" => "statistics-enabled", > "value" => true, > "operation-headers" => { > "caller-type" => "user", > "access-mechanism" => "NATIVE" > } > }]: java.lang.StackOverflowError > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:418) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) > at org.jboss.as.controller.CapabilityRegistry.getDependentCapabilityStatus(CapabilityRegistry.java:426) > at org.jboss.as.controller.CapabilityRegistry.getCapabilityStatus(CapabilityRegistry.java:392) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak edited comment on WFLY-12486 at 12/17/19 11:04 AM: ------------------------------------------------------------------ PR from from WFLY-12758 (https://github.com/wildfly/wildfly/pull/12836) fixes OOME on heap but introduces thread leak. Use can use this test to see thread leak: {code} git clone git@github.com:mnovak1/eap-microprofile-test-suite.git cd eap-microprofile-test-suite git checkout EAP7-1347 mvn clean verify -DfailIfNoTests=false -Darquillian.deploymentExportPath=target/deployments/ -Djboss.home=$WILDFLY_HOME -P mp-ft -Dtest=UndeployDeployTest#testRedeploy -- CONNECT VISUALVM TO RUNNING WF SERVER --- {code} See attached: wildfly-thread-leak.png was (Author: mnovak): PR from from WFLY-12758 (https://github.com/wildfly/wildfly/pull/12836) fixes OOME on heap but introduces thread leak. Use can use this test to see thread leak: {code} git clone git@github.com:mnovak1/eap-microprofile-test-suite.git cd eap-microprofile-test-suite git checkout EAP7-1347 mvn clean verify -DfailIfNoTests=false -Darquillian.deploymentExportPath=target/deployments/ -Djboss.home=$WILDFLY_HOME -P mp-ft -Dtest=UndeployDeployTest#testRedeploy -- CONNECT VISUALVM TO RUNNING WF SERVER --- {code} See: !wildfly-thread-leak.png! > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak edited comment on WFLY-12486 at 12/17/19 11:03 AM: ------------------------------------------------------------------ PR from from WFLY-12758 (https://github.com/wildfly/wildfly/pull/12836) fixes OOME on heap but introduces thread leak. Use can use this test to see thread leak: {code} git clone git@github.com:mnovak1/eap-microprofile-test-suite.git cd eap-microprofile-test-suite git checkout EAP7-1347 mvn clean verify -DfailIfNoTests=false -Darquillian.deploymentExportPath=target/deployments/ -Djboss.home=$WILDFLY_HOME -P mp-ft -Dtest=UndeployDeployTest#testRedeploy -- CONNECT VISUALVM TO RUNNING WF SERVER --- {code} See: !wildfly-thread-leak.png! was (Author: mnovak): PR from from WFLY-12758 (https://github.com/wildfly/wildfly/pull/12836) fixus OOME on heap but introduces thread leak. Use can use this test to see thread leak: {code} git clone git@github.com:mnovak1/eap-microprofile-test-suite.git cd eap-microprofile-test-suite git checkout EAP7-1347 mvn clean verify -DfailIfNoTests=false -Darquillian.deploymentExportPath=target/deployments/ -Djboss.home=$WILDFLY_HOME -P mp-ft -Dtest=UndeployDeployTest#testRedeploy -- CONNECT VISUALVM TO RUNNING WF SERVER --- {code} > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak updated WFLY-12486: ---------------------------------- Attachment: wildfly-thread-leak.png > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFLY-12486: --------------------------------------- PR from from WFLY-12758 (https://github.com/wildfly/wildfly/pull/12836) fixus OOME on heap but introduces thread leak. Use can use this test to see thread leak: {code} git clone git@github.com:mnovak1/eap-microprofile-test-suite.git cd eap-microprofile-test-suite git checkout EAP7-1347 mvn clean verify -DfailIfNoTests=false -Darquillian.deploymentExportPath=target/deployments/ -Djboss.home=$WILDFLY_HOME -P mp-ft -Dtest=UndeployDeployTest#testRedeploy -- CONNECT VISUALVM TO RUNNING WF SERVER --- {code} > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Attachments: memory-leak-bad.png, memory-leak-good.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2019