[JBoss JIRA] (DROOLS-4258) DMN UX - overlay information about a single scenario run
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4258?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-4258:
-----------------------------------------
Assignee: Margot Menestrot (was: Tao Zhu)
> DMN UX - overlay information about a single scenario run
> --------------------------------------------------------
>
> Key: DROOLS-4258
> URL: https://issues.jboss.org/browse/DROOLS-4258
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Margot Menestrot
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze the execution of a *single scenario* in the DMN model
> - user clicks on "a link" related to the scenario to analyze
> - user lands on DMN editor with overlay information about decision executed, decision failed and for each decision the possibility see actual and expected value (from the scenario) and to open an executed decision table to see which row has been evaluated
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4257) DMN UX - overlay information about an entire simulation execution
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4257?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-4257:
-------------------------------------------
[~mmenestr] [~danielezonca] if this is something that needs to be resolved for the DMN editor specifically, please feel free to reassign it to me.
> DMN UX - overlay information about an entire simulation execution
> -----------------------------------------------------------------
>
> Key: DROOLS-4257
> URL: https://issues.jboss.org/browse/DROOLS-4257
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Margot Menestrot
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze coverage information of {color:red}the *whole* simulation{color}
> - user clicks on "a link" near global coverage information
> - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4257) DMN UX - overlay information about an entire simulation execution
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-4257?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-4257:
-----------------------------------------
Assignee: Margot Menestrot (was: Tao Zhu)
> DMN UX - overlay information about an entire simulation execution
> -----------------------------------------------------------------
>
> Key: DROOLS-4257
> URL: https://issues.jboss.org/browse/DROOLS-4257
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.24.0.Final
> Reporter: Daniele Zonca
> Assignee: Margot Menestrot
> Priority: Major
> Labels: ScenarioSimulation, UX, UXTeam, drools-tools
>
> Related to https://issues.jboss.org/browse/DROOLS-3731
> This task will cover this use case:
> - user creates a DMN model
> - user creates a Test Scenario with some scenarios
> - user executes the Test Scenario
> - user open Coverage Report
> - user wants to analyze coverage information of {color:red}the *whole* simulation{color}
> - user clicks on "a link" near global coverage information
> - user lands on DMN editor with overlay information about number of time each decision has been executed, number of time each decision succeed/fail (maybe with different colors?)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-1771) Serialization is triggering rule multiple times
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-1771?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1771:
--------------------------------
Sprint: 2019 Week 32-34 (was: 2019 Week 29-31)
> Serialization is triggering rule multiple times
> ------------------------------------------------
>
> Key: DROOLS-1771
> URL: https://issues.jboss.org/browse/DROOLS-1771
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.2.0.Final, 7.3.0.Final
> Reporter: Christopher Brecht
> Assignee: Mario Fusco
> Priority: Major
> Attachments: EventA.java, Person.java, Reproducer.java
>
>
> I attached a reproducer of the problem. If I am executing the rules without serialization everything is working correctly. You can see the output we expect without serialization.
> The EventA at 3:00:30 shouldn’t trigger the rule one at time 3:05:00. Using serialization, event/rule triggering seems to ignore the temporal order of timed events.
> +*WITH SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@614aeccc[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@444548a0[value=0,timestamp=Fri Jan 01 03:00:30 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@773c0293[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@319854f0[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@415156bf[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
> +*WITHOUT SERIALIZATION *+
> STATE OUT Fri Jan 01 03:03:00 CET 2010 com.reproducer.EventA@659925f4[value=1,timestamp=Fri Jan 01 03:02:00 CET 2010]
> STATE IN Fri Jan 01 03:05:00 CET 2010 com.reproducer.EventA@562c877a[value=0,timestamp=Fri Jan 01 03:04:00 CET 2010]
> STATE OUT Fri Jan 01 03:07:00 CET 2010 com.reproducer.EventA@3b569985[value=1,timestamp=Fri Jan 01 03:06:00 CET 2010]
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFCORE-4395) The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check.
by Ashley Abdel-Sayed (Jira)
[ https://issues.jboss.org/browse/WFCORE-4395?page=com.atlassian.jira.plugi... ]
Ashley Abdel-Sayed reassigned WFCORE-4395:
------------------------------------------
Assignee: Ashley Abdel-Sayed
> The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check.
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-4395
> URL: https://issues.jboss.org/browse/WFCORE-4395
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Ashley Abdel-Sayed
> Priority: Major
>
> If possible the mappers should be flagged as being mutually exclusive, however failing that the validation should happen during Stage.MODEL.
> Presently this leads to an unsatisifed dependency: -
> {noformat}
> 14:21:59,055 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("security-domain" => "demon-domain")
> ]) - failure description: {
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.demo-realm"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.demon-domain.initial is missing [org.wildfly.security.security-realm.demo-realm]"]
> }
> {noformat}
> Despite this error the underlying cause is not logged at any level.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2356) RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2356?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2356:
--------------------------------
If you describe the problem you want to solve with this design, I can perhaps suggest something equivalent that solves your problem.
Closing this issue for now.
> RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2356
> URL: https://issues.jboss.org/browse/JGRP-2356
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0
> Environment: Java: jdk1.8.0_212
> OS: Windows 7 / Linux(ubuntu)
> Reporter: Ziro Tanaka
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
> Attachments: JChannelRunner.java, coordinator_log.txt, coordinator_threaddump.txt, joinner_log.txt
>
>
> Create RpcDispatcher that works with ForkChannel and set MembershipListener.
> If you make a synchronous call with RpcDispatcher in MembershipListener#viewAccepted, no response will be returned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2356) RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2356?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2356:
--------------------------------
OK, so what you're trying to do is bad and is not guaranteed to work (see below for an explanation)!
It works if you run the code in {{viewAccepted()}} in a separate thread (see below), but that's bad, too!
{code:java}
public void viewAccepted(final View new_view) {
Runnable view_handler=() -> {
System.out.println("viewAccepted:start");
try {
MethodCall call=new MethodCall(Boe1.class.getMethod("boeee"));
RequestOptions options=new RequestOptions(ResponseMode.GET_ALL, 0, true, null)
.setFlags(Message.Flag.OOB);
dispatcher1.callRemoteMethods(null, call, options);
}
catch(final Exception e) {
e.printStackTrace();
}
System.out.println("viewAccepted:end");
};
new Thread(view_handler).start(); // run in the background
}
{code}
OK, so here's the real issue: when you have view \{A,B\}, and C joins, then the following can happen:
* At time T0, A and B install new view \{A,B,C\}
* At time T50, C installs the new view, too
* If A and B invoke a blocking RPC (on A, B and C) *before T50 has been reached*, C will drop the RPC, because it is not yet member of the group!
* This means that A and B will block, possibly forever (depending on the RPC's RequestOptions), until C's response has been received.
Also, as I said before, invoking an RPC in {{viewAccepted()}} is bad practice and discouraged!
> RpcDispatcher#callRemoteMethods does not work while calling MembershipListener#viewAccepted when using ForkChannel.
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JGRP-2356
> URL: https://issues.jboss.org/browse/JGRP-2356
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.0
> Environment: Java: jdk1.8.0_212
> OS: Windows 7 / Linux(ubuntu)
> Reporter: Ziro Tanaka
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.3
>
> Attachments: JChannelRunner.java, coordinator_log.txt, coordinator_threaddump.txt, joinner_log.txt
>
>
> Create RpcDispatcher that works with ForkChannel and set MembershipListener.
> If you make a synchronous call with RpcDispatcher in MembershipListener#viewAccepted, no response will be returned.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months