[Red Hat JIRA] (DROOLS-4605) DMN alpha network
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-4605?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-4605:
-----------------------------------
Sprint: 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 34-36 (from Aug 17), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> DMN alpha network
> -----------------
>
> Key: DROOLS-4605
> URL: https://issues.redhat.com/browse/DROOLS-4605
> Project: Drools
> Issue Type: Story
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Luca Molteni
> Priority: Major
>
> *Motivation*: a DMN decision table can be evaluated faster than naive algorithm by translating it into a Rete/Phreak, but the current kie7 approach is suffering from performance bottleneck artificially induced by use of kie7 rule units, which provide more harm than benefit to perfomance (performance is actually worst for most "realistic" cases).
> *Goals*: a POC to understand what’s need to be done to support the alpha network compiler (wihout kie7 rule units) in DMN. We currently estimate it will take us 1 to 2 summer sprints and the output will be more epics to implement this feature.
> *Impact*: alpha network compiler code refactors for the better use of.
> One part of the POC was to hard-code the alpha network for a specific table ([DROOLS-4566]) the remained of the poc is to generalize the approach further to fully assess the impacts thanks to the poc.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5778) Rule evaluation optimization : alpha node range index additional enhancements
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5778?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5778:
-----------------------------------
Sprint: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Rule evaluation optimization : alpha node range index additional enhancements
> -----------------------------------------------------------------------------
>
> Key: DROOLS-5778
> URL: https://issues.redhat.com/browse/DROOLS-5778
> Project: Drools
> Issue Type: Story
> Components: core engine
> Affects Versions: 7.45.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Motivation: This Story follows up DROOLS-5631 to embrace additional enhancements related to alpha node range index.
> Goals: Better rule execution performance.
> Impact: Better rule execution performance. It might have slight overhead during rule build time.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5876) [Test Scenario Editor] Display actual test results instead of a generic message
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5876?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5876:
-----------------------------------
Sprint: 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 52-03 (from Dec 21))
> [Test Scenario Editor] Display actual test results instead of a generic message
> -------------------------------------------------------------------------------
>
> Key: DROOLS-5876
> URL: https://issues.redhat.com/browse/DROOLS-5876
> Project: Drools
> Issue Type: Enhancement
> Reporter: Yeser Amer
> Assignee: Yeser Amer
> Priority: Major
> Labels: ScenarioSimulation
>
> In the second row, in the attached test scenario execution result, it gives an error on the List(3) value.
> When I hover over it, I don’t get to see the values of the list, generated by the test scenario, but only this generic message:
> "Error message: Impossible to find elements in the collection to satisfy the conditions"
> It would be handy to see, as, with single values, the list of the actual values generated so that I can compare them with my list of expected values. Now, the user doesn’t have a clue where to look.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5282) Client side FEEL
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5282?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5282:
-----------------------------------
Sprint: 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28), 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27), 2020 Week 34-36 (from Aug 17), 2020 Week 37-39 (from Sep 7), 2020 Week 40-42 (from Sep 28), 2020 Week 43-45 (from Okt 19), 2020 Week 46-48 (from Nov 9), 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Client side FEEL
> ----------------
>
> Key: DROOLS-5282
> URL: https://issues.redhat.com/browse/DROOLS-5282
> Project: Drools
> Issue Type: Epic
> Components: DMN Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> Make kie-dmn-feel usable in the client side.
> Notes:
> * FEEL functions use reflection, but many if not all of them can be hard coded
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (DROOLS-5230) Managing a List of structures in Test Scenario editor produces an Exception
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5230?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5230:
-----------------------------------
Sprint: 2020 Week 16-18 (from Apr 13), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 16-18 (from Apr 13), 2020 Week 52-03 (from Dec 21))
> Managing a List of structures in Test Scenario editor produces an Exception
> ---------------------------------------------------------------------------
>
> Key: DROOLS-5230
> URL: https://issues.redhat.com/browse/DROOLS-5230
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.34.0.Final
> Reporter: Tracy Hires
> Assignee: Yeser Amer
> Priority: Critical
> Attachments: Error screen shot.png, test_scenario_list_exception.zip
>
>
> When trying to delete an item from a list of structures with nested structures in the scenario editor, an exception is thrown with a message that is not helpful to the end user.
> Log entry is:
> ```
> ^[[0m^[[31m17:16:51,564 ERROR [org.kie.workbench.common.services.backend.logger.GenericErrorLoggerServiceImpl] (default task-415) Error from user: xxxxx Error ID: -881202734 Location: LibraryPerspective|$ProjectScreen[!Worg.kie.dmn.decision.navigator,EDiagramEditorPropertiesScreen,Eorg.drools.scenariosimulation.TestTools?scesimeditorid=1,!Eorg.drools.scenariosimulation.TestTools?scesimeditorid=2,Eorg.docks.PlaceHolder?name=testRunnerReportingPanel,Worg.kie.guvnor.explorer,],DMNDiagramEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/main/resources/Math%2520Functions.dmn&file_name=Math%20Functions.dmn&has_version_support=true,DMNDiagramEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/main/resources/Divide.dmn&file_name=Divide.dmn&has_version_support=true,org.kie.workbench.common.screens.messageconsole.MessageConsole,,AddAssetsScreen,ScenarioSimulationEditor?path_uri=default://master@dm-ai/XmlValidationBug/src/test/resources/Test%2520Math%2520Functions.scesim&file_name=Test%20Math%20Functions.scesim&has_version_support=true Exception: Uncaught exception: Exception caught: (TypeError) : Cannot read property 'Tc' of undefined Caused by: (TypeError) : Cannot read property 'Tc' of undefined
> ```
> From UI I could see: `Uncaught exception: Exception caught: (TypeError) : Cannot read property 'Tc' of undefined Caused by: (TypeError) : Cannot read property 'Tc' of undefined`
> (Screenshot is attached)
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
[~ochaloup]
I did this change and tested de start/stop operations on Wildfly 18.0.1 and 20.0.1
{code:java}
cat > ${JBOSS_HOME}/domain/configuration/wildfly-config.xml <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<authentication-client xmlns="urn:elytron:1.0">
<authentication-rules>
<rule use-configuration="jta">
<match-abstract-type name="jta" authority="jboss" />
</rule>
</authentication-rules>
<authentication-configurations>
<configuration name="jta">
<sasl-mechanism-selector selector="DIGEST-MD5" />
<providers>
<use-service-loader />
</providers>
<set-user-name name="ejbserver" />
<credentials>
<clear-password password="ejb" />
</credentials>
<set-mechanism-realm name="ApplicationRealm" />
</configuration>
</authentication-configurations>
</authentication-client>
</configuration>
EOF
{code}
{code:java}
SECURITY_OPTIONS="-Dwildfly.config.url=$JBOSS_HOME/domain/configuration/wildfly-config.xml"
{code}
{code:java}
# Change remote outbout protocol
/profile=$PROFILE_NAME/subsystem=remoting/remote-outbound-connection=remote-workflow-connection:write-attribute(name=protocol,value=remote+http)
/profile=$PROFILE_NAME/subsystem=remoting/remote-outbound-connection=remote-emissor-email-connection:write-attribute(name=protocol,value=remote+http)
/profile=$PROFILE_NAME/subsystem=remoting/remote-outbound-connection=remote-erp-connection:write-attribute(name=protocol,value=remote+http)
{code}
{code:java}
# Set tx node id as unique
/host=$HOSTNAME/server-config=$SERVER_NAME/system-property=jboss.tx.node.id:add(value=$SERVER_NAME,boot-time=true)
{code}
And after stop and start de Wildfly instance I got this log after start and the server didn't stop again.
{code:java}
07:01,462 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception ARJUNA016099: Unknown error code:0: javax.transaction.xa.XAException: WFHTTP000008: Authentication failed
at org.wildfly.http-client.transaction@1.0.21.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
at org.wildfly.transaction.client@1.1.11.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:213)
at org.wildfly.transaction.client@1.1.11.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:209)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:659)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:240)
at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182)
at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
Caused by: java.lang.SecurityException: WFHTTP000008: Authentication failed
at org.wildfly.http-client.common@1.0.21.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$0(HttpTargetContext.java:198)
at org.wildfly.http-client.common@1.0.21.Final//org.wildfly.httpclient.common.HttpConnectionPool.runPending(HttpConnectionPool.java:134)
at org.wildfly.http-client.common@1.0.21.Final//org.wildfly.httpclient.common.HttpConnectionPool.getConnection(HttpConnectionPool.java:83)
at org.wildfly.http-client.common@1.0.21.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$null$1(HttpTargetContext.java:193)
at org.jboss.xnio@3.8.1.Final//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.jboss.xnio@3.8.1.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1145)
at org.jboss.xnio@3.8.1.Final//org.xnio.ChannelListeners$DrainListener.handleEvent(ChannelListeners.java:1125)
at org.wildfly.http-client.common@1.0.21.Final//org.wildfly.httpclient.common.HttpTargetContext$1$1.lambda$completed$4(HttpTargetContext.java:203)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
The server just works fine after delete data and temp folders
{code:java}
sudo rm -rf /app/wildfly/domain/data/servers/{server-name}
sudo rm -rf /app/wildfly/domain/tmp/servers/{server-name}
{code}
it looks like there's something broken on persisted transaction data.
I don't know what could be the consequences of doing this on production enviroments after undeployment or stop operations.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
5 years, 2 months