[JBoss JIRA] (DROOLS-2952) Hierarhical DataSource
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2952?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2952:
----------------------------------
Story Points: 8
> Hierarhical DataSource
> ----------------------
>
> Key: DROOLS-2952
> URL: https://issues.jboss.org/browse/DROOLS-2952
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> A really useful addition to DataSources would be scoped hierarchy.
> Lets say I make DataSource d1, and unit u1 is instantiated with it.
> I then want to instantiate d2, where d1 is the parent. I then instantiate u2 with d2.
> That means u2 can seemlessly see and react to all the data in d2 and d1. u1 can only see and react to u1.
> If u2 does inserts, those go into d2.
> If u2 is garbage collected and no references remain on d2, it is also GC'd. This allows a for temporary and local DataSources, scoped to a given unit.
> We can then add control structure methods such as:
> moveAllToParent()
> This would move all the FHs in d2 into d1. We might do this if u2 successfully finishes and d2 is about to be discarded, but we want to keep the results.
> For a given DataSuorce we should be able to determine if it's root, or get it's level. We should always be able to get and insert into root, parent, or any numerically specific level.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3015) [DMN Designer] Prohibit parallel item definition edition
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3015?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3015:
--------------------------------
Issue Type: Task (was: Enhancement)
> [DMN Designer] Prohibit parallel item definition edition
> --------------------------------------------------------
>
> Key: DROOLS-3015
> URL: https://issues.jboss.org/browse/DROOLS-3015
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Labels: drools-tools
> Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-24 13-00-45.png
>
>
> We should prohibit parallel edit operation of item definitions in managa custom data type dialog. It brings troubles in different scenarios:
> h2. Save parent item
> # Open attached dmn model
> # Invoke manage custom data type dialog
> # Expand *tProfile* item
> # Click on edit next to *tProfile (Structure)*
> # Click on edit next to *Name (string)*
> # Change *Name* to *Name_updated*
> # Change *tProfile* to *tProfile_updated*
> # Click *Save* next *tProfile_updated*
> # Save button for *Name_updated* will disappear
> # Changes saved just for parent item *tProfile_updated*
> h2. Save referred items
> # Open attached dmn model
> # Invoke manage custom data type dialog
> # Click on edit next to *tGender (string)*
> # Click on edit next to *tGenders (tGender)*
> # Rename *tGender* to *tGender_updated*
> # Click *Save* next *tGender_updated*
> # The data type select box for *tGenders* will disappear, see
> ## !Screenshot from 2018-09-24 13-00-45.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1669) NullPointerException in FlatQueryResults.<init> ("left join" query)
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1669?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-1669:
----------------------------------
Story Points: 5
> NullPointerException in FlatQueryResults.<init> ("left join" query)
> -------------------------------------------------------------------
>
> Key: DROOLS-1669
> URL: https://issues.jboss.org/browse/DROOLS-1669
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.5.0.Final
> Environment: Win7 x64, Tomcat 9, workbench-built DRL, managed KIE Server execution
> Reporter: Russell Morrisey
> Assignee: Mario Fusco
>
> The following DRL query passes build and validation in the workbench, but fails at runtime in KIE Server:
> {code:java}
> query "questionsKnowledge" ()
> $question: Question()
> $visible: QuestionVisible(question == $question) or not QuestionVisible(question == $question)
> end
> {code}
> The intent is that $visible may or may not be bound, depending on whether QuestionVisible is present. It looks like this causes an error in FlatQueryResults.(init):
> {code:java}
> 15:59:30.897 ERROR o.k.s.s.d.DroolsKieContainerCommandServiceImpl - Error calling container 'qna2'
> java.lang.NullPointerException: null
> at org.drools.core.QueryResultsRowImpl.getFactHandle(QueryResultsRowImpl.java:99) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.QueryResultsRowImpl.getFactHandle(QueryResultsRowImpl.java:95) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.runtime.rule.impl.FlatQueryResults.<init>(FlatQueryResults.java:116) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.command.runtime.rule.QueryCommand.execute(QueryCommand.java:109) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.command.runtime.rule.QueryCommand.execute(QueryCommand.java:39) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:137) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:254) ~[drools-core-6.5.0.Final.jar:6.5.0.Final]
> at org.kie.server.services.drools.RulesExecutionService.call(RulesExecutionService.java:52) ~[kie-server-services-drools-6.5.0.Final.jar:6.5.0.Final]
> at org.kie.server.services.drools.DroolsKieContainerCommandServiceImpl.callContainer(DroolsKieContainerCommandServiceImpl.java:69) ~[kie-server-services-drools-6.5.0.Final.jar:6.5.0.Final
> ]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:72) [kie-server-rest-drools-6.5.0.Final.jar:6.5.0.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2133) Rule Unit unbind using `run` causes wrong lookup of DS on the wrong unit
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2133?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2133:
----------------------------------
Story Points: 5
> Rule Unit unbind using `run` causes wrong lookup of DS on the wrong unit
> ------------------------------------------------------------------------
>
> Key: DROOLS-2133
> URL: https://issues.jboss.org/browse/DROOLS-2133
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
>
> Please reference test {{testGuardAndRunBack}}
> {code:java}
> public static class MainHouseUnit implements RuleUnit {
> private DataSource<Date> now;
> private DataSource<String> part;
> private DataSource<Boolean> switch1;
> public MainHouseUnit() {
> super();
> }
> public DataSource<Date> getNow() {
> return now;
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Boolean> getSwitch1() {
> return switch1;
> }
> }
> public static class DayPartUnit implements RuleUnit {
> private DataSource<Date> now;
> private DataSource<Date> aScopedDS;
> private DataSource<String> part;
> public DayPartUnit() {
> super();
> }
> public DataSource<Date> getNow() {
> return now;
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Date> getaScopedDS() {
> return aScopedDS;
> }
> }
> public static class SwitchUnit implements RuleUnit {
> private DataSource<String> part;
> private DataSource<Boolean> switch1;
> public SwitchUnit() {
> super();
> }
> public DataSource<String> getPart() {
> return part;
> }
> public DataSource<Boolean> getSwitch1() {
> return switch1;
> }
> }
> private KieBase kieBaseMainGuardSubunitRunBackToMain(boolean currentStyle) {
> // use "hammer" approach with external multiple call to fire, or "drools.run()" approach in rules.
> System.out.println("Running with style: " + currentStyle);
> String drl1 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(MainHouseUnit.class) + "\n" +
> "import " + DayPartUnit.class.getCanonicalName() + "\n" +
> "import " + SwitchUnit.class.getCanonicalName() + "\n" +
> "rule GuardDayPartUnit when\n" +
> " Object() from now \n" +
> " not( String() from part ) \n" +
> "then\n" +
> " System.out.println(\"Guarding DayPartUnit\");\n" +
> " drools.guard(DayPartUnit.class);\n" +
> "end\n" +
> "rule GuardSwitchUnit when\n" +
> " String() from part \n" +
> " not( Boolean() from switch1 ) \n" +
> "then\n" +
> " System.out.println(\"Guarding SwitchUnit\");\n" +
> " drools.guard(SwitchUnit.class);\n" +
> "end\n";
> String drl2 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(DayPartUnit.class) + "\n" +
> "import " + MainHouseUnit.class.getCanonicalName() + "\n" +
> "rule doDayPartUnit when\n" +
> " $n : Object() from now \n" +
> "then\n" +
> " System.out.println(\"Inside DayPartUnit: \"+$n);\n" +
> " part.insert(\"Morning\");\n" +
> (currentStyle ? "//" : "") + " drools.run(MainHouseUnit.class);\n" +
> "end\n";
> String drl3 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(SwitchUnit.class) + "\n" +
> "import " + MainHouseUnit.class.getCanonicalName() + "\n" +
> "rule doSwitchUnit when\n" +
> " $n : String() from part \n" +
> "then\n" +
> " System.out.println(\"Inside SwitchUnit: \"+$n);\n" +
> " switch1.insert(true);\n" +
> (currentStyle ? "//" : "") + " drools.run(MainHouseUnit.class);\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent(drl1, ResourceType.DRL)
> .addContent(drl2, ResourceType.DRL)
> .addContent(drl3, ResourceType.DRL)
> .build();
> return kbase;
> }
> @Test
> public void testMainGuardSubunitRunBackToMain_usingHammerStyle() throws Exception {
> KieBase kbase = kieBaseMainGuardSubunitRunBackToMain(true);
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("now", LocalDateTime.now());
> executor.newDataSource("part");
> executor.newDataSource("aScopedDS");
> DataSource<Boolean> switch1 = executor.newDataSource("switch1");
> RuleUnit adultUnit = new MainHouseUnit();
> executor.run(adultUnit);
> // need a second, "hammer" run.
> executor.run(adultUnit);
> assertEquals(true, switch1.iterator().next());
> }
> @Test
> public void testMainGuardSubunitRunBackToMain_usingRunStyle() throws Exception {
> KieBase kbase = kieBaseMainGuardSubunitRunBackToMain(false);
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("now", LocalDateTime.now());
> executor.newDataSource("part");
> executor.newDataSource("aScopedDS");
> DataSource<Boolean> switch1 = executor.newDataSource("switch1");
> RuleUnit adultUnit = new MainHouseUnit();
> executor.run(adultUnit); // FAILs with trying to lookup method getaScopedDS() on the MainHouseUnit (which is not correct unit).
> // does NOT need a second, "hammer" run.
> assertEquals(true, switch1.iterator().next());
> }
> public static class EmptyUnit implements RuleUnit {
> public EmptyUnit() {
> // no-args constructor.
> }
> }
> public static class StringDSUnit implements RuleUnit {
> private DataSource<String> strings;
> public StringDSUnit() {
> // no-args constructor.
> }
> public DataSource<String> getStrings() {
> return strings;
> }
> }
> @Test
> public void testGuardAndRunBack() {
> String drl1 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(EmptyUnit.class) + "\n" +
> "import " + StringDSUnit.class.getCanonicalName() + "\n" +
> "rule RGuard when\n" +
> "then\n" +
> " System.out.println(\"Guarding StringDSUnit\");\n" +
> " drools.guard(StringDSUnit.class);\n" +
> "end\n";
> String drl2 = "package org.drools.compiler.integrationtests\n" +
> "unit " + getCanonicalSimpleName(StringDSUnit.class) + "\n" +
> "import " + EmptyUnit.class.getCanonicalName() + "\n" +
> "rule RGoBack when\n" +
> "then\n" +
> " System.out.println(\"Inside StringDSUnit: \");\n" +
> " drools.run(EmptyUnit.class);\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent(drl1, ResourceType.DRL)
> .addContent(drl2, ResourceType.DRL)
> .build();
> RuleUnitExecutor executor = RuleUnitExecutor.create().bind(kbase);
> executor.newDataSource("strings", "abc", "xyz");
> RuleUnit adultUnit = new EmptyUnit();
> executor.run(adultUnit); // FAILs with trying to lookup method getStrings() on the EmptyUnit (which is not correct unit).
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3015) [DMN Designer] Prohibit parallel item definition edition
by Jozef Marko (JIRA)
Jozef Marko created DROOLS-3015:
-----------------------------------
Summary: [DMN Designer] Prohibit parallel item definition edition
Key: DROOLS-3015
URL: https://issues.jboss.org/browse/DROOLS-3015
Project: Drools
Issue Type: Enhancement
Components: DMN Editor
Affects Versions: 7.12.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: DMCommunity Challenge - March 2017.dmn, Screenshot from 2018-09-24 13-00-45.png
We should prohibit parallel edit operation of item definitions in managa custom data type dialog. It brings troubles in different scenarios:
h2. Save parent item
# Open attached dmn model
# Invoke manage custom data type dialog
# Expand *tProfile* item
# Click on edit next to *tProfile (Structure)*
# Click on edit next to *Name (string)*
# Change *Name* to *Name_updated*
# Change *tProfile* to *tProfile_updated*
# Click *Save* next *tProfile_updated*
# Save button for *Name_updated* will disappear
# Changes saved just for parent item *tProfile_updated*
h2. Save referred items
# Open attached dmn model
# Invoke manage custom data type dialog
# Click on edit next to *tGender (string)*
# Click on edit next to *tGenders (tGender)*
# Rename *tGender* to *tGender_updated*
# Click *Save* next *tGender_updated*
# The data type select box for *tGenders* will disappear, see
## !Screenshot from 2018-09-24 13-00-45.png|thumbnail!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2968) Improve stateless ksession throughput performance
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2968?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2968:
----------------------------------
Story Points: 8
> Improve stateless ksession throughput performance
> -------------------------------------------------
>
> Key: DROOLS-2968
> URL: https://issues.jboss.org/browse/DROOLS-2968
> Project: Drools
> Issue Type: Feature Request
> Reporter: Mark Proctor
> Assignee: Mario Fusco
> Labels: MDP_BRAINFARTS
>
> Stateless access has become too heavy. We should look at streamlining the api, to avoid unnecessary work, and unnecessary (on demand) object creation. For example we know if rules need timers, avoid the timer creation if not necessary.
> Also we should look at (with evaluation first) to determine if a Three local cache of ksessions, with reset, will help improve GC impact.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-2996) Existing Rules are not working as expected after migrating the Drools version from 6.0.3 to 7.4.1.Final
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2996?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-2996:
----------------------------------
Story Points: 3
> Existing Rules are not working as expected after migrating the Drools version from 6.0.3 to 7.4.1.Final
> -------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-2996
> URL: https://issues.jboss.org/browse/DROOLS-2996
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.4.1.Final
> Reporter: Prameela Pod
> Assignee: Mario Fusco
> Attachments: DroolsTestPortlet.zip, logs.txt
>
>
> After drools migration from 6.0.3 to 7.4.1.Final version , modify property in 1st rule not validating conditions in 2nd rule.
> Ex: modify($alarm){setEVENTO_EN_TAREA("YES")} - In 1st rule then condition
> $alarm: ALARMA_ERICSSON_2G("NO" == getEVENTO_EN_TAREA()) - When condition in 2nd rule.
> If getEVENTO_EN_TAREA() = "YES" then only it should go inside 2nd rule.But here in this case getEVENTO_EN_TAREA()="YES" or "NO" - For both cases 2nd rule when condition is matched and going inside then condition.Which is wrong
> Please find the attached sample test project with logs.
> Kindly let me know additional information is required.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-1409) Infinite loop when using maps
by Tibor Zimányi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1409?page=com.atlassian.jira.plugi... ]
Tibor Zimányi updated DROOLS-1409:
----------------------------------
Story Points: 3
> Infinite loop when using maps
> -----------------------------
>
> Key: DROOLS-1409
> URL: https://issues.jboss.org/browse/DROOLS-1409
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final, 6.4.0.Final, 6.5.0.Final
> Environment: Windows/Linux /MacOs
> Reporter: mourad ouachani
> Assignee: Mario Fusco
> Attachments: engineMapBug.zip
>
>
> Infinite loop when using maps instead collections.
> The problem appears before the 10th iteration, however if you run it 10 times it could end properly without infinite loop.
>
> We thought it could be linked to the concurrent access to HashMap and we tried with concurrent HashMap but still got the same problem.
> It could be probably linked to the fact that we use maps not only to store the result of some rules evaluation but also as a functional way to prevent rule to be fired again (see rule "FLG1" and the condition "FLG1 not memberof matchMap"
> Thanks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months