April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3794) Inconsistent null check between JITed and non-JITed "contains"/"memberOf" condition

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3794?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3794: -------------------------------- Story Points: 3 > Inconsistent null check between JITed and non-JITed "contains"/"memberOf" condition > ----------------------------------------------------------------------------------- > > Key: DROOLS-3794 > URL: https://issues.jboss.org/browse/DROOLS-3794 > Project: Drools > Issue Type: Bug > Affects Versions: 7.19.0.Final > Reporter: Max Zerzouri > Assignee: Mario Fusco > Priority: Major > Attachments: DroolsTest.java, drl.drl > > > A condition such as {{list contains item}} or {{item memberOf list}} seems to correspond to {{EvaluatorHelper.contains(list, item)}}, but when this has been compiled through {{ASMConditionEvaluatorJitter}}, the condition includes the additional constraint, {{item != null}}. This differs to the non-JITed condition, which does not require {{item}} to be non-null. > Attached an example {{.drl}} file as an example case, and a simple runner. Running {{java DroolsTest 14}} triggers the issue for me (resulting in an infinite loop in this case), but since the recompilation is asynchronous, it might require a larger number. > Decompiled {{ConditionalEvaluator}} for the test case below: > {code:java} > import droolstest.Bar; > import droolstest.Foo; > import java.util.List; > import org.drools.core.common.InternalFactHandle; > import org.drools.core.common.InternalWorkingMemory; > import org.drools.core.rule.Declaration; > import org.drools.core.rule.constraint.ConditionEvaluator; > import org.drools.core.rule.constraint.EvaluatorHelper; > import org.drools.core.spi.Tuple; > public class ConditionEvaluator4471f59df9b54235ba1be708b5c480da > implements ConditionEvaluator { > private static final String EXPRESSION = "!( foo.barNames contains name )"; > private final Declaration[] declarations; > public boolean evaluate(InternalFactHandle internalFactHandle, InternalWorkingMemory internalWorkingMemory, Tuple tuple) { > Tuple tuple2 = tuple; > Foo foo = (Foo)this.declarations[0].getValue(internalWorkingMemory, tuple2.getFactHandle().getObject()); > List list = foo.getBarNames(); > String string = ((Bar)internalFactHandle.getObject()).getName(); > return !(list == null ? false : (string == null ? false : EvaluatorHelper.contains((Object)list, (Object)string))); > } > public ConditionEvaluator4471f59df9b54235ba1be708b5c480da(Declaration[] arrdeclaration) { > this.declarations = arrdeclaration; > } > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3794) Inconsistent null check between JITed and non-JITed "contains"/"memberOf" condition

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3794?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3794: -------------------------------- Sprint: 2019 Week 14-16 > Inconsistent null check between JITed and non-JITed "contains"/"memberOf" condition > ----------------------------------------------------------------------------------- > > Key: DROOLS-3794 > URL: https://issues.jboss.org/browse/DROOLS-3794 > Project: Drools > Issue Type: Bug > Affects Versions: 7.19.0.Final > Reporter: Max Zerzouri > Assignee: Mario Fusco > Priority: Major > Attachments: DroolsTest.java, drl.drl > > > A condition such as {{list contains item}} or {{item memberOf list}} seems to correspond to {{EvaluatorHelper.contains(list, item)}}, but when this has been compiled through {{ASMConditionEvaluatorJitter}}, the condition includes the additional constraint, {{item != null}}. This differs to the non-JITed condition, which does not require {{item}} to be non-null. > Attached an example {{.drl}} file as an example case, and a simple runner. Running {{java DroolsTest 14}} triggers the issue for me (resulting in an infinite loop in this case), but since the recompilation is asynchronous, it might require a larger number. > Decompiled {{ConditionalEvaluator}} for the test case below: > {code:java} > import droolstest.Bar; > import droolstest.Foo; > import java.util.List; > import org.drools.core.common.InternalFactHandle; > import org.drools.core.common.InternalWorkingMemory; > import org.drools.core.rule.Declaration; > import org.drools.core.rule.constraint.ConditionEvaluator; > import org.drools.core.rule.constraint.EvaluatorHelper; > import org.drools.core.spi.Tuple; > public class ConditionEvaluator4471f59df9b54235ba1be708b5c480da > implements ConditionEvaluator { > private static final String EXPRESSION = "!( foo.barNames contains name )"; > private final Declaration[] declarations; > public boolean evaluate(InternalFactHandle internalFactHandle, InternalWorkingMemory internalWorkingMemory, Tuple tuple) { > Tuple tuple2 = tuple; > Foo foo = (Foo)this.declarations[0].getValue(internalWorkingMemory, tuple2.getFactHandle().getObject()); > List list = foo.getBarNames(); > String string = ((Bar)internalFactHandle.getObject()).getName(); > return !(list == null ? false : (string == null ? false : EvaluatorHelper.contains((Object)list, (Object)string))); > } > public ConditionEvaluator4471f59df9b54235ba1be708b5c480da(Declaration[] arrdeclaration) { > this.declarations = arrdeclaration; > } > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3820) Create a Quarkus extension for Drools

by Mario Fusco (Jira)

Mario Fusco created DROOLS-3820: ----------------------------------- Summary: Create a Quarkus extension for Drools Key: DROOLS-3820 URL: https://issues.jboss.org/browse/DROOLS-3820 Project: Drools Issue Type: Task Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3751) Add decision-table support in Submarine

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3751?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3751: -------------------------------- Sprint: 2019 Week 14-16 > Add decision-table support in Submarine > --------------------------------------- > > Key: DROOLS-3751 > URL: https://issues.jboss.org/browse/DROOLS-3751 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > Labels: submarine > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

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

by David Lloyd (Jira)

[ https://issues.jboss.org/browse/JBREM-1340?page=com.atlassian.jira.plugin... ] David Lloyd commented on JBREM-1340: ------------------------------------ I think the problem is unbounded thread creation in the old JBoss management client. It really seems like a problem that was fixed years ago. You would need to upgrade your client library and configure it to connect via {{remote}} to be compatible with the old server you're using. > 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)

7 years, 1 month

1
0
0 / 0

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

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-3818?page=com.atlassian.jira.plugi... ] Klara Kufova updated DROOLS-3818: --------------------------------- Tester: Klara Kufova > 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)

7 years, 1 month

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: ----------------------------------- Description: 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. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc) (was: 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.) > 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. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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: ----------------------------------- 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)

7 years, 1 month

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)

7 years, 1 month

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)

7 years, 1 month

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 April 2019