[JBoss JIRA] (DROOLS-5132) DMN Drools TCK runner updates
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5132?page=com.atlassian.jira.plug... ]
Matteo Mortari edited comment on DROOLS-5132 at 3/6/20 8:14 AM:
----------------------------------------------------------------
CRITERIA FOR RESOLVING THIS JIRA: the commit https://github.com/kiegroup/drools/commit/ca70199cf5edccf5261f153dde3296c... will have been REVERTED.
was (Author: tari_manga):
CRITERIA FOR RESOLVING THIS JIRA: the commit generated with https://github.com/kiegroup/drools/pull/2806 will have been REVERTED.
> DMN Drools TCK runner updates
> -----------------------------
>
> Key: DROOLS-5132
> URL: https://issues.redhat.com/browse/DROOLS-5132
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
> Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
> In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
> Example, in case
> * the result from a DMN expression evaluation is null,
> * the TCK expect a null,
> * IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
> https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
> Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
> Now is aligned as explained.
> Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
> Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, https://github.com/dmn-tck/tck/pull/360 this can be reverted.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5132) DMN Drools TCK runner updates
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5132?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5132:
-----------------------------------
Description:
Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
Example, in case
* the result from a DMN expression evaluation is null,
* the TCK expect a null,
* IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
Now is aligned as explained.
Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, the commit https://github.com/kiegroup/drools/commit/ca70199cf5edccf5261f153dde3296c... can be reverted.
was:
Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
Example, in case
* the result from a DMN expression evaluation is null,
* the TCK expect a null,
* IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
Now is aligned as explained.
Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, https://github.com/dmn-tck/tck/pull/360 this can be reverted.
> DMN Drools TCK runner updates
> -----------------------------
>
> Key: DROOLS-5132
> URL: https://issues.redhat.com/browse/DROOLS-5132
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
> Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
> In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
> Example, in case
> * the result from a DMN expression evaluation is null,
> * the TCK expect a null,
> * IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
> https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
> Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
> Now is aligned as explained.
> Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
> Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, the commit https://github.com/kiegroup/drools/commit/ca70199cf5edccf5261f153dde3296c... can be reverted.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5112) DMN kie-server wrong cast message reported on FEEL failure
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5112?page=com.atlassian.jira.plug... ]
Matteo Mortari resolved DROOLS-5112.
------------------------------------
Resolution: Done
Was demonstrated by this reproducer: https://github.com/kiegroup/drools/commit/c465098ca8358dee1398d8a088bca04...
which was incorporated in [DROOLS-5116] work.
Resolving this jira as [DROOLS-5116] is resolved accordingly.
> DMN kie-server wrong cast message reported on FEEL failure
> ----------------------------------------------------------
>
> Key: DROOLS-5112
> URL: https://issues.redhat.com/browse/DROOLS-5112
> Project: Drools
> Issue Type: Bug
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> {code:java}
> 10:38:53,533 ERROR [org.kie.dmn.feel.runtime.functions.AbsFunction] (default task-26) Error trying to call function abs.: java.lang.ClassCastException: org.kie.server.services.prometheus.PrometheusMetricsDMNListener cannot be cast to org.kie.dmn.api.feel.runtime.events.FEELEventListener
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.kie.dmn.feel.lang.impl.FEELEventListenersManager.notifyListeners(FEELEventListenersManager.java:71)
> at org.kie.dmn.feel.lang.impl.FEELEventListenersManager.notifyListeners(FEELEventListenersManager.java:82)
> at org.kie.dmn.feel.lang.impl.EvaluationContextImpl.notifyEvt(EvaluationContextImpl.java:178)
> at org.kie.dmn.feel.runtime.functions.BaseFEELFunction.lambda$invokeReflectively$3(BaseFEELFunction.java:97)
> at org.kie.dmn.feel.util.Either.cata(Either.java:70)
> at org.kie.dmn.feel.runtime.functions.BaseFEELFunction.invokeReflectively(BaseFEELFunction.java:96)
> at org.kie.dmn.feel.lang.ast.FunctionInvocationNode.invokeTheFunction(FunctionInvocationNode.java:112)
> at org.kie.dmn.feel.lang.ast.FunctionInvocationNode.evaluate(FunctionInvocationNode.java:90)
> at org.kie.dmn.feel.lang.impl.CompiledExpressionImpl.apply(CompiledExpressionImpl.java:47)
> at org.kie.dmn.feel.lang.impl.InterpretedExecutableExpression.apply(InterpretedExecutableExpression.java:38)
> at org.kie.dmn.feel.lang.impl.InterpretedExecutableExpression.apply(InterpretedExecutableExpression.java:24)
> at org.kie.dmn.feel.codegen.feel11.ProcessedExpression.apply(ProcessedExpression.java:114)
> at org.kie.dmn.feel.codegen.feel11.ProcessedExpression.apply(ProcessedExpression.java:22)
> at org.kie.dmn.feel.lang.impl.FEELImpl.evaluate(FEELImpl.java:167)
> at org.kie.dmn.core.ast.DMNLiteralExpressionEvaluator.evaluate(DMNLiteralExpressionEvaluator.java:73)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateDecision(DMNRuntimeImpl.java:664)
> at org.kie.dmn.core.impl.DMNRuntimeImpl.evaluateAll(DMNRuntimeImpl.java:163)
> at org.kie.dmn.core.internal.utils.DMNEvaluationUtils.evaluate(DMNEvaluationUtils.java:87)
> at org.kie.dmn.core.internal.utils.DMNEvaluationUtils.evaluate(DMNEvaluationUtils.java:51)
> at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:184)
> at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (DROOLS-5132) DMN Drools TCK runner updates
by Matteo Mortari (Jira)
[ https://issues.redhat.com/browse/DROOLS-5132?page=com.atlassian.jira.plug... ]
Matteo Mortari updated DROOLS-5132:
-----------------------------------
Sprint: (was: 2020 Week 10-12 (from Mar 2))
> DMN Drools TCK runner updates
> -----------------------------
>
> Key: DROOLS-5132
> URL: https://issues.redhat.com/browse/DROOLS-5132
> Project: Drools
> Issue Type: Task
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Major
>
> Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo.
> Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360
> In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners.
> Example, in case
> * the result from a DMN expression evaluation is null,
> * the TCK expect a null,
> * IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test).
> https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7...
> Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one!
> Now is aligned as explained.
> Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359)
> Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, https://github.com/dmn-tck/tck/pull/360 this can be reverted.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (JGRP-2451) FD_ALL3: improvements over FD_ALL
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2451?page=com.atlassian.jira.plugin... ]
Bela Ban updated JGRP-2451:
---------------------------
Description:
Improvements to {{FD_ALL}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
It is crucial that setting the timestamp in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
was:
Improvements to {{FD_ALL}}.
* Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
* When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
It is crucial that setting the timestamp in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
However, this is only feasible with sending a message N-1 times (e.g. TCP); for UDP we don't have such an 'anycast' available.
> FD_ALL3: improvements over FD_ALL
> ---------------------------------
>
> Key: JGRP-2451
> URL: https://issues.redhat.com/browse/JGRP-2451
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 5.0
>
>
> Improvements to {{FD_ALL}}.
> * Messages should count as heartbeats ({{msg_counts_as_heartbeat}} should be *default*, and as such, deprecated/removed).
> * When a multicast message is sent before {{interval}} elapsed, we suppress sending a heartbeat
> It is crucial that setting the timestamp in the map is quick, especially since this is done on every message. This should not be an issue, as we fetch the current time from the time service, which does *not* call {{System.nanoTime()}} or {{System.currentTimeMillis()}} every time.
> The advantage is that we only send heartbeats when there is no (multicast) traffic, and we don't suspect a member P when heartbeats have been missing despite receiving traffic from P.
> We need to think about whether to consider unicast messages, too, on the sender side: we could populate a bit map with messages sent to members: on a unicast message to P, P's bit would be set in the bit. On a multicast message, all bits would be set. Then, we could selectively send heartbeats only to members with bits set to 0.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13006) KUBE_PING Occasional NPE on shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13006?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13006:
----------------------------------
Affects Version/s: 19.0.0.Beta2
> KUBE_PING Occasional NPE on shutdown
> -------------------------------------
>
> Key: WFLY-13006
> URL: https://issues.redhat.com/browse/WFLY-13006
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 20.0.0.Beta1
>
>
> 05:52:55,313 ERROR [org.jgroups.util.TimeScheduler3] (thread-6,null,xa-load-2) JGRP000169: failed executing task MERGE3: InfoSender: java.lang.NullPointerException
> at org.jgroups.protocols.kubernetes.KUBE_PING.readAll(KUBE_PING.java:313)
> at org.jgroups.protocols.kubernetes.KUBE_PING.findMembers(KUBE_PING.java:206)
> at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:216)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:241)
> at org.jgroups.protocols.Discovery.down(Discovery.java:384)
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:413)
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:328)
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:362)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748)
> https://github.com/jgroups-extras/jgroups-kubernetes/issues/39
> https://github.com/jgroups-extras/jgroups-kubernetes/pull/88
> Will be resolved with a next jgroups-kubernetes upgrade.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13006) KUBE_PING Occasional NPE on shutdown
by Radoslav Husar (Jira)
[ https://issues.redhat.com/browse/WFLY-13006?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFLY-13006:
----------------------------------
Fix Version/s: 20.0.0.Beta1
> KUBE_PING Occasional NPE on shutdown
> -------------------------------------
>
> Key: WFLY-13006
> URL: https://issues.redhat.com/browse/WFLY-13006
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 19.0.0.Beta2
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Fix For: 20.0.0.Beta1
>
>
> 05:52:55,313 ERROR [org.jgroups.util.TimeScheduler3] (thread-6,null,xa-load-2) JGRP000169: failed executing task MERGE3: InfoSender: java.lang.NullPointerException
> at org.jgroups.protocols.kubernetes.KUBE_PING.readAll(KUBE_PING.java:313)
> at org.jgroups.protocols.kubernetes.KUBE_PING.findMembers(KUBE_PING.java:206)
> at org.jgroups.protocols.Discovery.invokeFindMembers(Discovery.java:216)
> at org.jgroups.protocols.Discovery.findMembers(Discovery.java:241)
> at org.jgroups.protocols.Discovery.down(Discovery.java:384)
> at org.jgroups.protocols.MERGE3$InfoSender.run(MERGE3.java:413)
> at org.jgroups.util.TimeScheduler3$Task.run(TimeScheduler3.java:328)
> at org.jgroups.util.TimeScheduler3$RecurringTask.run(TimeScheduler3.java:362)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.jboss.as.clustering.jgroups.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:52)
> at java.lang.Thread.run(Thread.java:748)
> https://github.com/jgroups-extras/jgroups-kubernetes/issues/39
> https://github.com/jgroups-extras/jgroups-kubernetes/pull/88
> Will be resolved with a next jgroups-kubernetes upgrade.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months