[JBoss JIRA] (DROOLS-3822) DMN DT analysis extended Validation API support
by Matteo Mortari (Jira)
Matteo Mortari created DROOLS-3822:
--------------------------------------
Summary: DMN DT analysis extended Validation API support
Key: DROOLS-3822
URL: https://issues.jboss.org/browse/DROOLS-3822
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Make DT Analysis flag available and behaving in all APIs of Validation, including fluent builders, so that regardless of single model / multiple models API it will perform the DT Analysis.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[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:
--------------------------------
Tester: Tibor Zimanyi
> 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)
6 years, 9 months
[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)
6 years, 9 months
[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)
6 years, 9 months
[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)
6 years, 9 months