April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3819) Rule Unit Handling: restore older behavior in new prototype

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3819: ----------------------------------- Story Points: 8 > Rule Unit Handling: restore older behavior in new prototype > ----------------------------------------------------------- > > Key: DROOLS-3819 > URL: https://issues.jboss.org/browse/DROOLS-3819 > Project: Drools > Issue Type: Bug > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, submarine > Fix For: 8.0.0.Final > > > I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3819) Rule Unit Handling: restore older behavior in new prototype

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3819: ----------------------------------- Sprint: (was: 2019 Week 14-16) > Rule Unit Handling: restore older behavior in new prototype > ----------------------------------------------------------- > > Key: DROOLS-3819 > URL: https://issues.jboss.org/browse/DROOLS-3819 > Project: Drools > Issue Type: Bug > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, submarine > Fix For: 8.0.0.Final > > > I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3819) Rule Unit Handling: restore older behavior in new prototype

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ] Edoardo Vacchi updated DROOLS-3819: ----------------------------------- Sprint: 2019 Week 14-16 > Rule Unit Handling: restore older behavior in new prototype > ----------------------------------------------------------- > > Key: DROOLS-3819 > URL: https://issues.jboss.org/browse/DROOLS-3819 > Project: Drools > Issue Type: Bug > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, submarine > Fix For: 8.0.0.Final > > > I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3819) Rule Unit Handling: restore older behavior in new prototype

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-3819: -------------------------------------- Summary: Rule Unit Handling: restore older behavior in new prototype Key: DROOLS-3819 URL: https://issues.jboss.org/browse/DROOLS-3819 Project: Drools Issue Type: Bug Reporter: Edoardo Vacchi Assignee: Edoardo Vacchi Fix For: 8.0.0.Final I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1340) Memory leak related to org.jboss.threads.JBossThreadFactory

by Adrián López (Jira)

[ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin... ] Adrián López updated JBREM-1340: -------------------------------- Attachment: lep2jia1-heapdump-1554113927775_Leak_Suspects.zip > Memory leak related to org.jboss.threads.JBossThreadFactory > ----------------------------------------------------------- > > Key: JBREM-1340 > URL: https://issues.jboss.org/browse/JBREM-1340 > Project: JBoss Remoting > Issue Type: Bug > Components: jmx remoting > Reporter: Adrián López > Priority: Major > Attachments: img-2019-04-01-130952.png, lep2jia1-heapdump-1554113927775_Leak_Suspects.zip > > > We have a memory leak when using the jboss-cli-client JAR inside of Jolokia. > Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%. > A heap dump analyzed with Eclipse MAT returns: > {code} > One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>". > The stacktrace of this Thread is available. See stacktrace. > Keywords > java.lang.ThreadGroup[] > org.jboss.modules.ModuleClassLoader @ 0xe04ffe20 > java.lang.ThreadGroup > {code} > Thread stack > {code} > HTTP-11 > at sun.misc.Unsafe.park(ZJ)V (Native Method) > at java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V (LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()V (AbstractQueuedSynchronizer.java:2043) > at java.util.concurrent.LinkedBlockingQueue.take()Ljava/lang/Object; (LinkedBlockingQueue.java:442) > at java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable; (ThreadPoolExecutor.java:1068) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1130) > at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:615) > at java.lang.Thread.run()V (Thread.java:745) > at org.jboss.threads.JBossThread.run()V (JBossThread.java:122) > {code} > I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there. > Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401] > Thanks -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3818) Assign a complex type object to a property with modified label leads to NPE

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ] Yeser Amer commented on DROOLS-3818: ------------------------------------ https://issues.jboss.org/secure/attachment/12448995/screencast-29-03-19-1... > Assign a complex type object to a property with modified label leads to NPE > --------------------------------------------------------------------------- > > Key: DROOLS-3818 > URL: https://issues.jboss.org/browse/DROOLS-3818 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBREM-1340) Memory leak related to org.jboss.threads.JBossThreadFactory

by Adrián López (Jira)

[ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin... ] Adrián López updated JBREM-1340: -------------------------------- Description: We have a memory leak when using the jboss-cli-client JAR inside of Jolokia. Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%. A heap dump analyzed with Eclipse MAT returns: {code} One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>". The stacktrace of this Thread is available. See stacktrace. Keywords java.lang.ThreadGroup[] org.jboss.modules.ModuleClassLoader @ 0xe04ffe20 java.lang.ThreadGroup {code} Thread stack {code} HTTP-11 at sun.misc.Unsafe.park(ZJ)V (Native Method) at java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V (LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()V (AbstractQueuedSynchronizer.java:2043) at java.util.concurrent.LinkedBlockingQueue.take()Ljava/lang/Object; (LinkedBlockingQueue.java:442) at java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable; (ThreadPoolExecutor.java:1068) at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1130) at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:615) at java.lang.Thread.run()V (Thread.java:745) at org.jboss.threads.JBossThread.run()V (JBossThread.java:122) {code} I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there. Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401] Thanks was: We have a memory leak when using the jboss-cli-client JAR inside of Jolokia. Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%. A heap dump analyzed with Eclipse MAT returns: {code} One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>". The stacktrace of this Thread is available. See stacktrace. Keywords java.lang.ThreadGroup[] org.jboss.modules.ModuleClassLoader @ 0xe04ffe20 java.lang.ThreadGroup {code} I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there. Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401] Thanks > Memory leak related to org.jboss.threads.JBossThreadFactory > ----------------------------------------------------------- > > Key: JBREM-1340 > URL: https://issues.jboss.org/browse/JBREM-1340 > Project: JBoss Remoting > Issue Type: Bug > Components: jmx remoting > Reporter: Adrián López > Priority: Major > Attachments: img-2019-04-01-130952.png, lep2jia1-heapdump-1554113927775_Leak_Suspects.zip > > > We have a memory leak when using the jboss-cli-client JAR inside of Jolokia. > Jolokia uses remoting to connect to the JMX of several JBoss servers. After running for some days, the Old Gen memory space reach 100%. > A heap dump analyzed with Eclipse MAT returns: > {code} > One instance of "java.lang.ThreadGroup" loaded by "<system class loader>" occupies 377.517.248 (87,28%) bytes. The instance is referenced by org.jboss.threads.JBossThread @ 0xe0a81ef0 HTTP-11 , loaded by "org.jboss.modules.ModuleClassLoader @ 0xe04ffe20". The memory is accumulated in one instance of "java.lang.ThreadGroup[]" loaded by "<system class loader>". > The stacktrace of this Thread is available. See stacktrace. > Keywords > java.lang.ThreadGroup[] > org.jboss.modules.ModuleClassLoader @ 0xe04ffe20 > java.lang.ThreadGroup > {code} > Thread stack > {code} > HTTP-11 > at sun.misc.Unsafe.park(ZJ)V (Native Method) > at java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V (LockSupport.java:186) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()V (AbstractQueuedSynchronizer.java:2043) > at java.util.concurrent.LinkedBlockingQueue.take()Ljava/lang/Object; (LinkedBlockingQueue.java:442) > at java.util.concurrent.ThreadPoolExecutor.getTask()Ljava/lang/Runnable; (ThreadPoolExecutor.java:1068) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Ljava/util/concurrent/ThreadPoolExecutor$Worker;)V (ThreadPoolExecutor.java:1130) > at java.util.concurrent.ThreadPoolExecutor$Worker.run()V (ThreadPoolExecutor.java:615) > at java.lang.Thread.run()V (Thread.java:745) > at org.jboss.threads.JBossThread.run()V (JBossThread.java:122) > {code} > I have created also another [issue|https://issues.jboss.org/browse/JBTHR-72] to jboss-threads, but looks the problem is not there. > Same for [Jolokia|https://github.com/rhuss/jolokia/issues/401] > Thanks -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3818) Assign a complex type object to a property with modified label leads to NPE

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-3818: ------------------------------- Story Points: 3 > Assign a complex type object to a property with modified label leads to NPE > --------------------------------------------------------------------------- > > Key: DROOLS-3818 > URL: https://issues.jboss.org/browse/DROOLS-3818 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3818) Assign a complex type object to a property with modified label leads to NPE

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-3818: ------------------------------- Labels: ScenarioSimulation (was: ) > Assign a complex type object to a property with modified label leads to NPE > --------------------------------------------------------------------------- > > Key: DROOLS-3818 > URL: https://issues.jboss.org/browse/DROOLS-3818 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3818) Assign a complex type object to a property with modified label leads to NPE

by Yeser Amer (Jira)

[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ] Yeser Amer updated DROOLS-3818: ------------------------------- Component/s: Scenario Simulation and Testing > Assign a complex type object to a property with modified label leads to NPE > --------------------------------------------------------------------------- > > Key: DROOLS-3818 > URL: https://issues.jboss.org/browse/DROOLS-3818 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019