[Red Hat JIRA] (DROOLS-5988) DMN Alpha Network - Verify multithread instantiation of Feel Class singleton instance
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5988?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5988:
---------------------------------
Description:
Using Alpha Network in DMN, Feel test classes instantiated lazily the first time they're called and set to a static field.
That might generate some problem while evaluating decision tables with more than one thread.
was:
Using Alpha Network in DMN, Feel test classes are generated before the instantiation of Alpha Nodes.
We should avoid generating identical classes for identical feel constraints and especially when the alpha nodes are shared, as they won't be referenced.
> DMN Alpha Network - Verify multithread instantiation of Feel Class singleton instance
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-5988
> URL: https://issues.redhat.com/browse/DROOLS-5988
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Using Alpha Network in DMN, Feel test classes instantiated lazily the first time they're called and set to a static field.
> That might generate some problem while evaluating decision tables with more than one thread.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years
[Red Hat JIRA] (DROOLS-5987) DMN Alpha Network - Do not create unit tests for shared alpha nodes
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5987?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5987:
---------------------------------
Description:
Using Alpha Network in DMN, Feel test classes are generated before the instantiation of Alpha Nodes.
We should avoid generating identical classes for identical feel constraints and especially when the alpha nodes are shared, as they won't be referenced.
was:It's possible to have multiple decision table in a DMN file, that means that we should generate different AlphaNetwork creation classes and avoid collision on Feel tests
> DMN Alpha Network - Do not create unit tests for shared alpha nodes
> -------------------------------------------------------------------
>
> Key: DROOLS-5987
> URL: https://issues.redhat.com/browse/DROOLS-5987
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Using Alpha Network in DMN, Feel test classes are generated before the instantiation of Alpha Nodes.
> We should avoid generating identical classes for identical feel constraints and especially when the alpha nodes are shared, as they won't be referenced.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years
[Red Hat JIRA] (WFCORE-4291) Restore legacy (not "graceful") startup mode
by Jason Lee (Jira)
[ https://issues.redhat.com/browse/WFCORE-4291?page=com.atlassian.jira.plug... ]
Jason Lee commented on WFCORE-4291:
-----------------------------------
I can't make any promises, but we're trying hard to make it in for 23.
> Restore legacy (not "graceful") startup mode
> --------------------------------------------
>
> Key: WFCORE-4291
> URL: https://issues.redhat.com/browse/WFCORE-4291
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management
> Reporter: Vladimir Grabarchuk
> Assignee: Jason Lee
> Priority: Major
>
> Please allow a configurable legacy startup mode which was the default before WF11, when components can service HTTP requests as soon as they are deployed, not when the container deploys all components.
> The use case for this is the following: there is a configuration service component upon which other components depend for configuration data, requested and served via a HTTP request. With the new "graceful startup" this scenario no longer seems possible, as it results in read timeouts, mis-configured artifacts, and failed deployments altogether.
> If generally feasible, another value of the *--start-mode=legacy* seems appropriate to accommodate the original (legacy) behavior.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years
[Red Hat JIRA] (DROOLS-5986) DMN Alpha Network - Multiple Decision Tables in DMN File
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5986?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5986:
---------------------------------
Description: It's possible to have multiple decision table in a DMN file, that means that we should generate different AlphaNetwork creation classes and avoid collision on Feel tests (was: When using Alpha Network for DMN there's only a single hardcoded Hit Policy in which the first results of the output is returned.
Support different Hit Policies)
> DMN Alpha Network - Multiple Decision Tables in DMN File
> --------------------------------------------------------
>
> Key: DROOLS-5986
> URL: https://issues.redhat.com/browse/DROOLS-5986
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> It's possible to have multiple decision table in a DMN file, that means that we should generate different AlphaNetwork creation classes and avoid collision on Feel tests
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years
[Red Hat JIRA] (DROOLS-5985) DMN Alpha Network - Support different Hit Policies
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5985?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5985:
---------------------------------
Description:
When using Alpha Network for DMN there's only a single hardcoded Hit Policy in which the first results of the output is returned.
Support different Hit Policies
was:
Currently alpha range index is not enabled probably because AlphaNetworkCreation.createAlphaNode() doesn't set an index to a constraint for "Application Risk Score" in DMNDecisionTableAlphaSupportingTest (= ConstraintType is UNKNOWN so CompositeObjectSinkAdapter.isRangeIndexable() returns false.
Also we would need to change range index threshold to test easier).
> DMN Alpha Network - Support different Hit Policies
> --------------------------------------------------
>
> Key: DROOLS-5985
> URL: https://issues.redhat.com/browse/DROOLS-5985
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> When using Alpha Network for DMN there's only a single hardcoded Hit Policy in which the first results of the output is returned.
> Support different Hit Policies
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years
[Red Hat JIRA] (DROOLS-5984) DMN Alpha Network - Range Indexing
by Luca Molteni (Jira)
[ https://issues.redhat.com/browse/DROOLS-5984?page=com.atlassian.jira.plug... ]
Luca Molteni updated DROOLS-5984:
---------------------------------
Description: Currently alpha range index is not enabled probably because AlphaNetworkCreation.createAlphaNode() doesn't set an index to a constraint for "Application Risk Score" in DMNDecisionTableAlphaSupportingTest (= ConstraintType is UNKNOWN so CompositeObjectSinkAdapter.isRangeIndexable() returns false. Also we would need to change range index threshold to test easier). We will be able to enhance it in another JIRA? (was: Verify that indexes are generated correctly.
This should also give some performance different, try measure it with a benchmark.)
> DMN Alpha Network - Range Indexing
> ----------------------------------
>
> Key: DROOLS-5984
> URL: https://issues.redhat.com/browse/DROOLS-5984
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Luca Molteni
> Assignee: Luca Molteni
> Priority: Major
>
> Currently alpha range index is not enabled probably because AlphaNetworkCreation.createAlphaNode() doesn't set an index to a constraint for "Application Risk Score" in DMNDecisionTableAlphaSupportingTest (= ConstraintType is UNKNOWN so CompositeObjectSinkAdapter.isRangeIndexable() returns false. Also we would need to change range index threshold to test easier). We will be able to enhance it in another JIRA?
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
4 years