[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
!AFTER.png!
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
> !AFTER.png!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Description:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
!BEFORE.png!
to this:
was:
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Attachment: AFTER.png
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: AFTER.png, BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
> !BEFORE.png!
> to this:
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-2799:
--------------------------------------
Summary: DMN Optimize DT parameter binding for compilation
Key: DROOLS-2799
URL: https://issues.jboss.org/browse/DROOLS-2799
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
Attachments: BEFORE.png
Currently, DMN layer Evaluator method:
{code:java}
org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
{code}
calls down to FEEL layer function:
{code:java}
org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
{code}
In order to evaluate Decision Table using DecisionTableImpl.
Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2799) DMN Optimize DT parameter binding for compilation
by Matteo Mortari (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2799?page=com.atlassian.jira.plugi... ]
Matteo Mortari updated DROOLS-2799:
-----------------------------------
Attachment: BEFORE.png
> DMN Optimize DT parameter binding for compilation
> -------------------------------------------------
>
> Key: DROOLS-2799
> URL: https://issues.jboss.org/browse/DROOLS-2799
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Attachments: BEFORE.png
>
>
> Currently, DMN layer Evaluator method:
> {code:java}
> org.kie.dmn.core.ast.DMNDTExpressionEvaluator.evaluate(org.kie.dmn.api.core.event.DMNRuntimeEventManager, org.kie.dmn.api.core.DMNResult)
> {code}
> calls down to FEEL layer function:
> {code:java}
> org.kie.dmn.feel.runtime.functions.DTInvokerFunction.invoke(org.kie.dmn.feel.lang.EvaluationContext, java.lang.Object[ ])
> {code}
> In order to evaluate Decision Table using DecisionTableImpl.
> Currently, the whole Decision Table FEEL expression/UT are compiled to CompiledExpression and this enable for fast performance during execution and multiple evaluation, however, the parameter binding for the invocation from the DMN layer does not leverage FEEL expression compilation of the parameters ( information/knowledge requirements coming from the DRG graph ) hence the parameter binding slow down across several evaluation.
> The current proposal leverage compilation for the parameter (names) which are actually FEEL expression, in order to move from this scenario:
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3977:
------------------------------------------
[~pferraro] [~jmesnil] I've done some quick usage analysis of the SocketBindingManager stuff to get a sense of how often it's being done as intended.
tl;dr; Fairly often for unicast server sockets. Not always. AFAICT never for client sockets. Given how often it's not done right, and how fussy doing it right is, perhaps we should skip the isBound stuff and just rely on the service being UP/DOWN.
Probably the big difficulty in dropping SocketBindingManager altogether is the 'bound' attribute on the socket-binding=X resourcees. Granted, the data it returns is often wrong, but that's the place where the original purpose of all this surfaces in our management API.
I've attached a usages search for ManagedBindingRegistry.registerBinding. That shows where it looks to be being done right. The remoting subsystem stuff ends up being used by all our remoting connectors. UnnamedManagedBindingRegistry is only used by UndertowHttpManagementService. The SocketBinding.createXXXSocket methods, which IIRC was a key way services were intended to ensure the SBM got used, are not used at all.
> Changing multicast address in socket binding does not trigger server to set reload-required
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3977
> URL: https://issues.jboss.org/browse/WFCORE-3977
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
> Attachments: WFCORE-3977_binding_usage.txt
>
>
> Found this by accident when debugging a clustering test case.
> If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
> This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Edson Tirelli updated DROOLS-2787:
----------------------------------
Attachment: type_definitions.pdf
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, add_basic.png, treegrid.png, type_definitions.pdf
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Edson Tirelli commented on DROOLS-2787:
---------------------------------------
[~uxdlc] in line with what [~manstis] said, I am attaching an idea. This is *not* a mockup, just trying to convey the idea.
There are three basic scenarios:
* either the user selects a simple type (like number, text, etc), in which case he only selects the "type" of the field, no name.
* or the user selects a name and an existing type, like he can create type "tAge" that is an alias for type "Number", or "tEmployee" that is an alias for type "tPerson".
* or the user creates a structured type with fields, in which case he has to select a name and create all the fields, like "tPerson", of type "Structure" with fields "age" (number) and "address" (text).
These 3 scenarios have to be clear and supported, and that is the idea I tried to express with the attached PDF.
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, add_basic.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (WFCORE-3977) Changing multicast address in socket binding does not trigger server to set reload-required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3977?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3977:
-------------------------------------
Attachment: WFCORE-3977_binding_usage.txt
> Changing multicast address in socket binding does not trigger server to set reload-required
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3977
> URL: https://issues.jboss.org/browse/WFCORE-3977
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 6.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Jeff Mesnil
> Attachments: WFCORE-3977_binding_usage.txt
>
>
> Found this by accident when debugging a clustering test case.
> If I start a server with profile standalone-full-ha and then modify the multicast address of a clustering related socket-binding, in this case, jgroups-mping, the server is not put into state reload-required.
> This causes a lot of problems in the testsuite which depends on configuring servers after startup and then restarting if necessary to pull in the changes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months
[JBoss JIRA] (DROOLS-2787) "Data Type" tree-grid table interactions.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2787?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-2787:
----------------------------------------
[~uxdlc] When it's a simple type you still need to specify the type of the simple type. Remember a simple type is in essence an alias for an existing type so "newPerson" would need a drop-down to select it's type not just a checkbox to declare it as a simple type. Perhaps we need something like this (in words here, or I can draw a diagram with pen and pencil!)
* When you first go to the "types dialog" you have 2 radio buttons; "Edit existing", "Define new"
* Select "Edit existing" you get a drop-down of the existing types to select from
* In both cases "edit" and "new" you also get two further radio buttons: "simple" or "structured"
* If "simple" you just get a field for name and a drop-down for type (listing existing types) everything else is hidden/disabled.
* If "structured" you get a text box for its name and the tree grid for it's component parts
> "Data Type" tree-grid table interactions.
> -----------------------------------------
>
> Key: DROOLS-2787
> URL: https://issues.jboss.org/browse/DROOLS-2787
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam, drools-tools
> Attachments: DROOLS-2738.bmpr, Screen Shot 2018-07-24 at 3.51.03 PM.png, add_basic.png, treegrid.png
>
>
> *Background*
> Persona: Business analyst or Rules practitioner
> Use Cases:
> As a user I want to:
> * *Edit* the list of Data Types, using the appropriate type considering the DMN model (eg: in the age line, we need to select "Numeric" in the combobox.)
> * *Add* a new data type, which might be a nested or otherwise complex object as defined by the (ItemDefinition.)
> * *Remove* Data Types from the list of available selections.
> * be prevented from making selections that are not valid or would cause an error.
> * know that when I edit a data type the changes will be updated in the DMN model.
> Functional considerations/ pre conditions:
> * Outside of simple view/select, Data Types list (and options) will be presented as a tree-grid within a modal dialog. Discussed in detail within Epic subtask for the same.
> * Design needs to be consistent with Stunner and PF components, such as: https://www.patternfly.org/pattern-library/widgets/#treegrid-table
> Verification conditions:
> * Scrum team and PO review.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 9 months