[JBoss JIRA] (DROOLS-1037) Parsing of a complex constraint with an || causes a RuntimeException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1037?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1037:
-------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1300692|https://bugzilla.redhat.com/show_bug.cgi?id=1300692] from ON_QA to VERIFIED
> Parsing of a complex constraint with an || causes a RuntimeException
> --------------------------------------------------------------------
>
> Key: DROOLS-1037
> URL: https://issues.jboss.org/browse/DROOLS-1037
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.0.Beta2
>
>
> Trying to compile a rule like the following
> {code}
> rule R when
> $p : Person( name == null || (name in (\"Alice\", \"Charlie\", \"David\"))==false )
> then
> list.add($p.getName());
> end
> {code}
> causes the following RuntimeException:
> {code}
> java.lang.RuntimeException
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:924)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteCompositeExpressions(PatternBuilder.java:919)
> at org.drools.compiler.rule.builder.PatternBuilder.rewriteOrExpressions(PatternBuilder.java:893)
> at org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:889)
> at org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:860)
> at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:715)
> at org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:580)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-998:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1302140|https://bugzilla.redhat.com/show_bug.cgi?id=1302140] from ON_QA to VERIFIED
> NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> ---------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-998
> URL: https://issues.jboss.org/browse/DROOLS-998
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1)
> Reporter: Christian Spurk
> Assignee: Mario Fusco
> Fix For: 6.4.0.Beta2
>
>
> The following {{NullPointerException}} occurs for the following rule:
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603)
> at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65)
> at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536)
> at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:142)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109)
> at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34)
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292)
> at Test.main(Test.java:13)
> {code}
> {code}
> rule "test"
> when
> not( String() )
> accumulate(
> Long();
> sum(1)
> )
> ( Boolean() or not( Float() ) )
> then
> insert(new String());
> end
> {code}
> (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.)
> I'm using a default KIE configuration to load the rule:
> {{kmodule.xml}}:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" />
> {code}
> {{Test.java}}:
> {code}
> import org.kie.api.KieBase;
> import org.kie.api.KieServices;
> import org.kie.api.runtime.StatelessKieSession;
> import org.kie.internal.command.CommandFactory;
> public class Test {
> public static void main(String[] args) {
> KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer()
> .getKieBase();
> StatelessKieSession session = kieBase.newStatelessKieSession();
> session.execute(CommandFactory.newFireAllRules());
> }
> }
> {code}
> This issue might be related with DROOLS-987.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1017) NPE deleting an expired event in equality mode
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1017?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1017:
-------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1295433|https://bugzilla.redhat.com/show_bug.cgi?id=1295433] from ON_QA to VERIFIED
> NPE deleting an expired event in equality mode
> ----------------------------------------------
>
> Key: DROOLS-1017
> URL: https://issues.jboss.org/browse/DROOLS-1017
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.0.Beta1
>
>
> Trying to delete an already expired event in equality mode causes the following NPE in the TMS:
> {code}
> java.lang.NullPointerException
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:506)
> at org.drools.core.common.NamedEntryPoint.delete(NamedEntryPoint.java:442)
> at org.drools.core.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1120)
> at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:121)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at org.drools.compiler.integrationtests.CepEspTest.testDeleteExpiredEventWithTimestampAndEqualityKey(CepEspTest.java:5682)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ELY-428) HTTP Mechanism configuration during deployment
by Pedro Igor (JIRA)
[ https://issues.jboss.org/browse/ELY-428?page=com.atlassian.jira.plugin.sy... ]
Pedro Igor commented on ELY-428:
--------------------------------
Yes, that was the outcome from our HTTP discussions.
However, I was wondering if we didn't consider use cases where the initialization can take some time, thus blocking the first request. You never know what people can do, so that can have some impact on the application as well in the server.
> HTTP Mechanism configuration during deployment
> ----------------------------------------------
>
> Key: ELY-428
> URL: https://issues.jboss.org/browse/ELY-428
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: HTTP
> Affects Versions: 1.0.2.Final
> Reporter: Pedro Igor
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 1.1.0.Beta5
>
>
> It should be possible to configure a HTTP mechanism during deployment in order to parse/load configuration and reuse it in subsequent requests to an application.
> The most common use case for that is around mechanisms that need to read some configuration from inside a deployment (or provided by the mech config) when it is being deployed to the server.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1098) Equals behaviour faulty when loading sessions after exception
by Artur Kronenberg (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1098?page=com.atlassian.jira.plugi... ]
Artur Kronenberg commented on DROOLS-1098:
------------------------------------------
So, in case anyone needs to work around this so that persistence is stable. (I hope/think). You can do that:
1. Create marker interface for objects that need de-duplication
2. create a rule:
{code:java}
rule "Schrodinger Rule"
no-loop true
salience 1 // this will make this rule the first to execute
when
$e : Equality();
$e2 : Equality( this == $e, eval($e != $e2) );
then
retract($e);
end
{code}
(I called it Schrodinger's rule because the facts are at the same time kinda equal and not equal :P )
This matches all facts, that have a different identity but are still equal and removes the duplicate automatically. I tested it with 30k facts and it runs in about 600 ms.
After this, one can switch their beliefe system to "identity", which fixes the session loading, and the rule implements the equals behaviour.
> Equals behaviour faulty when loading sessions after exception
> -------------------------------------------------------------
>
> Key: DROOLS-1098
> URL: https://issues.jboss.org/browse/DROOLS-1098
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Mac OS 10.10.5, Eclipse Mars Release, Java 1.8, Drools 6.3.0.Final
> Reporter: Artur Kronenberg
> Assignee: Mario Fusco
> Attachments: test-standalone.zip
>
>
> This is in a series of debugging and I think a few issues boil down to this:
> https://issues.jboss.org/browse/DROOLS-1093
> https://issues.jboss.org/browse/DROOLS-1097
> This bug demonstrates how two identical sessions with identical input and rules produce a NPE when loading with equals behaviour vs identity behaviour. I am currently battling that issue and looking for a workaround.
> Essentially, you can run the unit tests I attached in the test project: (ExceptionTest)
> testIdentity - passes
> testIdentityWithReload - passes
> testEquals - NPE
> testEqualsWithReload- NPE
> The tests do the same thing:
> * Create new persistent session
> * Load facts into it
> * Run 20 times either reloading the session (depending on the test cases) or using the old session. Each run, insert one fact and run all the rules. Eventually the equals tests (I believe after iteration 2) NPE when trying to deserialise the session. Identity has no issues and functions correctly.
> Let me know if you need anything else and please do let me know if there is a workaround. I am currently exploring the workaround avenue myself as well and will come back here with an update should I find one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-1007) ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1007?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1007:
-------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1291749|https://bugzilla.redhat.com/show_bug.cgi?id=1291749] from ON_QA to VERIFIED
> ArrayIndexOutOfBoundsException attempting to remove a rule containing a OR
> --------------------------------------------------------------------------
>
> Key: DROOLS-1007
> URL: https://issues.jboss.org/browse/DROOLS-1007
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.0.Beta1
>
>
> At the moment the association between a node and a rule is kept by a Map inside the node having the rule as key. This implementation is not taking count of the fact that the same node could be associated multiple times to the same rule that it is indeed what happens when a rule contains a OR.
> During the removal of such a rule the nodes of the rule are removed from the Rete starting from the RuleTerminalNodes (in this case the rule has more than one RTNs because of the OR). This means that when the first RTN is removed the Join and LIA nodes that are sources for that RTN at any level got completely disassociated from the rule when it is too early. That in the end causes the following exception when the engine tries to remove also the second RTN of that rule
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 1
> at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:171)
> at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:173)
> at org.drools.core.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:163)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1635)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1626)
> at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1610)
> at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1581)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (DROOLS-911) Kie Navigator does not recognize running EAP server
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-911?page=com.atlassian.jira.plugin... ]
Kris Verlaenen resolved DROOLS-911.
-----------------------------------
Fix Version/s: 6.4.0.CR2
Resolution: Done
Cloned bugzilla marked as resolved and verified.
> Kie Navigator does not recognize running EAP server
> ---------------------------------------------------
>
> Key: DROOLS-911
> URL: https://issues.jboss.org/browse/DROOLS-911
> Project: Drools
> Issue Type: Bug
> Components: eclipse plugin
> Affects Versions: 6.3.0.CR2
> Reporter: Tomas David
> Assignee: Robert (Bob) Brodt
> Labels: qe-recommend-fix-before-ga, reported-by-qe
> Fix For: 6.4.0.CR2
>
>
> Kie Navigator does not recognize running EAP server. Server should be listed in Kie Navigator view but there is only default link ("No servers available. Click this link to create a new server...") to the Servers view.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (LOGTOOL-99) Support for one-time messages
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGTOOL-99?page=com.atlassian.jira.plugin... ]
David Lloyd resolved LOGTOOL-99.
--------------------------------
Fix Version/s: (was: 2.1.0.Alpha1)
Resolution: Duplicate Issue
This is already done! Nifty.
> Support for one-time messages
> -----------------------------
>
> Key: LOGTOOL-99
> URL: https://issues.jboss.org/browse/LOGTOOL-99
> Project: Log Tool
> Issue Type: Feature Request
> Reporter: David Lloyd
> Assignee: James Perkins
>
> Add an annotation that indicates that a log message should only be logged one time. The imlpementation would use a private static final AtomicBoolean with CAS to ensure that the message is logged one time, guarding such messages with code that is something like this:
> {code}
> AtomicBoolean someMessageCalledOnce = this.someMessageCalledOnce;
> do {
> if (someMessageCalledOnce.get()) return;
> } while (! someMessageCalledOnce.compareAndSet(false, true));
> // ... log message here ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned WFLY-1066:
-------------------------------------
Assignee: Tristan Tarrant (was: Dominik Pospisil)
> Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1066
> URL: https://issues.jboss.org/browse/WFLY-1066
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Environment: Server running in Domain mode
> Reporter: Wolf-Dieter Fink
> Assignee: Tristan Tarrant
> Labels: clustering, domain, jgroups
>
> It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode.
> All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration.
> The domain server will receive the informations if a host-controller enrol and register server to a clustered server-group.
> So the configuration of the initial_hosts can be done automaticaly to avoid old entries which cause unnecessary checks and ensure that all active servers are known.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month