November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (REMJMX-156) Thread Leak in jboss-client on JMX remoting authentication failure

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/REMJMX-156?page=com.atlassian.jira.plugin... ] Yeray Borges resolved REMJMX-156. --------------------------------- Resolution: Duplicate Issue > Thread Leak in jboss-client on JMX remoting authentication failure > ------------------------------------------------------------------ > > Key: REMJMX-156 > URL: https://issues.jboss.org/browse/REMJMX-156 > Project: Remoting JMX > Issue Type: Bug > Reporter: Piotr Krokowski > Assignee: Darran Lofthouse > Attachments: JbossClientThreadLeakDemo.java, close.png > > > I've observed, that authentication failure, while connecting with jboss-client implementation of JMX remoting (remote+http) causes a thread leak. > Please find the attached code snippet to reproduce the faulty behavior. > The attached code produces following output in my case : > Thread count before starting: 2 > Active threads AFTER start: 2 > Connection failed. > Active threads AFTER after success: 7 > Connection failed. > Active threads AFTER after failure: 12 > Possible cause. > After an initial analisys I've observed that RemotingConnector.internalConnect throws an Exception, while having state set to UNUSED, while I'd actually expect it being set to OPEN, as connection and endpoint fields are already initialized. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2135) Rule compilation can fail when using an attribute/method of OOPath provided variable

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2135?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2135: -------------------------------- Sprint: BxMS70-Iteration7 > Rule compilation can fail when using an attribute/method of OOPath provided variable > ------------------------------------------------------------------------------------ > > Key: DROOLS-2135 > URL: https://issues.jboss.org/browse/DROOLS-2135 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Peter Mačkay > Assignee: Mario Fusco > Priority: Minor > > Having a test like this: > https://gist.github.com/mackaypeter/d8b576ce34d42794da559308b1854aff > Produces the following error: > {code} > Unable to Analyse Expression this.getName() == "joe": > [Error: unable to resolve method using strict-mode: org.drools.compiler.oopath.MyTest$Parent.getName()] > [Near : {... this.getName() == "joe" ....}] > ^ > [Line: 4, Column: 2] : [Rule name='R'] > {code} > It seems like it tries to look for the method definition in the Parent class instead of the Child class. The rule works correctly when there's a getName method defined in Parent. Meaning the rule compiles and fires correctly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2134) OOPathTest#testDeclarationOutsideOOPath fails with ClassCastException when jitting is enforced

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2134?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-2134: -------------------------------- Sprint: BxMS70-Iteration7 > OOPathTest#testDeclarationOutsideOOPath fails with ClassCastException when jitting is enforced > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-2134 > URL: https://issues.jboss.org/browse/DROOLS-2134 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.1.Final > Reporter: Peter Mačkay > Assignee: Mario Fusco > Priority: Minor > Labels: jitting > > When trying to run OOPathTest#testDeclarationOutsideOOPath [1] with enforced jitting, the test fails with following exception: > {code} > java.lang.RuntimeException: Error evaluating constraint 'this != $ic1' in [] > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:273) > at org.drools.core.rule.constraint.MvelConstraint.isAllowedCachedLeft(MvelConstraint.java:233) > at org.drools.core.common.DoubleBetaConstraints.isAllowedCachedLeft(DoubleBetaConstraints.java:109) > at org.drools.core.phreak.PhreakFromNode.propagate(PhreakFromNode.java:317) > at org.drools.core.phreak.PhreakFromNode.checkConstraintsAndPropagate(PhreakFromNode.java:290) > at org.drools.core.phreak.PhreakFromNode.doLeftInserts(PhreakFromNode.java:120) > at org.drools.core.phreak.PhreakFromNode.doNode(PhreakFromNode.java:68) > at org.drools.core.phreak.PhreakReactiveFromNode.doNode(PhreakReactiveFromNode.java:34) > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:392) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) > at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) > at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) > at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) > at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295) > at org.drools.compiler.oopath.OOPathTest.testDeclarationOutsideOOPath(OOPathTest.java:1010) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runner.JUnitCore.run(JUnitCore.java:137) > at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117) > at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234) > at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144) > Caused by: java.lang.ClassCastException: org.drools.compiler.oopath.model.TMFile cannot be cast to org.drools.compiler.oopath.model.TMFileSet > at ConditionEvaluator02d1ed6d278d48e7bf85d6c59d74e5c4.evaluate(Unknown Source) > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:271) > ... 48 more > {code} > [1]: https://github.com/kiegroup/drools/blob/6214852d8332b8708bc845794e3f2207c... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2144) Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2144?page=com.atlassian.jira.plugi... ] Matteo Mortari updated DROOLS-2144: ----------------------------------- Component/s: dmn engine > Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext > ----------------------------------------------------------------------------------------- > > Key: DROOLS-2144 > URL: https://issues.jboss.org/browse/DROOLS-2144 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2144) Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-2144: -------------------------------------- Summary: Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext Key: DROOLS-2144 URL: https://issues.jboss.org/browse/DROOLS-2144 Project: Drools Issue Type: Bug Reporter: Matteo Mortari Assignee: Edson Tirelli -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2144) Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2144?page=com.atlassian.jira.plugi... ] Matteo Mortari reassigned DROOLS-2144: -------------------------------------- Assignee: Matteo Mortari (was: Edson Tirelli) > Fix BaseFEELFunction.getCandidateMethod for non-custom empty param with EvaluationCotnext > ----------------------------------------------------------------------------------------- > > Key: DROOLS-2144 > URL: https://issues.jboss.org/browse/DROOLS-2144 > Project: Drools > Issue Type: Bug > Reporter: Matteo Mortari > Assignee: Matteo Mortari > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3426) AbstractSubsytemBaseTest shouldn't normalize subsystem xml if it isn't going to use that xml

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3426?page=com.atlassian.jira.plugi... ] Brian Stansberry closed WFCORE-3426. ------------------------------------ Resolution: Rejected Never mind, looking at the real code instead of a decompiled version I see this is deliberate, done for validation purposes. > AbstractSubsytemBaseTest shouldn't normalize subsystem xml if it isn't going to use that xml > -------------------------------------------------------------------------------------------- > > Key: WFCORE-3426 > URL: https://issues.jboss.org/browse/WFCORE-3426 > Project: WildFly Core > Issue Type: Enhancement > Components: Test Suite > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > AbstractSubsytemBaseTest.standardSubsystemTest is normalizing the subsystem xml even if comparing xml is turned off. Waste of time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3426) AbstractSubsytemBaseTest shouldn't normalize subsystem xml if it isn't going to use that xml

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3426: ---------------------------------------- Summary: AbstractSubsytemBaseTest shouldn't normalize subsystem xml if it isn't going to use that xml Key: WFCORE-3426 URL: https://issues.jboss.org/browse/WFCORE-3426 Project: WildFly Core Issue Type: Enhancement Components: Test Suite Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor AbstractSubsytemBaseTest.standardSubsystemTest is normalizing the subsystem xml even if comparing xml is turned off. Waste of time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime

by Matthew Stevens (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ] Matthew Stevens updated DROOLS-1825: ------------------------------------ Attachment: GDTColumns(a)2x.png GDTAnalysis(a)2x.png > [Guided Decision Table] Ability to change HIT policy in a decision table anytime > -------------------------------------------------------------------------------- > > Key: DROOLS-1825 > URL: https://issues.jboss.org/browse/DROOLS-1825 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Ivo Bek > Assignee: Toni Rikkola > Priority: Critical > Labels: UX > Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis(a)2x.png, GDTColumns(a)2x.png > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy. > Thus, it should be possible to change HIT policy in a decision table anytime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1825) [Guided Decision Table] Ability to change HIT policy in a decision table anytime

by Matthew Stevens (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugi... ] Matthew Stevens commented on DROOLS-1825: ----------------------------------------- Two very quick, rough mockups. If you want to go in this direction, I can refine these. # GDTAnalysis - shows the Analysis panel being readily available. # GDTColumns - shows columns in a panel. This would eliminate the need for the current Edit Columns button. Thank you, Matthew > [Guided Decision Table] Ability to change HIT policy in a decision table anytime > -------------------------------------------------------------------------------- > > Key: DROOLS-1825 > URL: https://issues.jboss.org/browse/DROOLS-1825 > Project: Drools > Issue Type: Enhancement > Components: Guided Decision Table Editor > Affects Versions: 7.1.0.Beta2 > Reporter: Ivo Bek > Assignee: Toni Rikkola > Priority: Critical > Labels: UX > Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy. > Thus, it should be possible to change HIT policy in a decision table anytime. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 November 2017