[JBoss JIRA] (DROOLS-5454) Please bring back the IDE-based 'Guided Rule Editor'
by Edson Tirelli (Jira)
[ https://issues.redhat.com/browse/DROOLS-5454?page=com.atlassian.jira.plug... ]
Edson Tirelli commented on DROOLS-5454:
---------------------------------------
[~id40417-citi] [~rick_wagner] unfortunately we can no longer develop or maintain an eclipse plugin. We have been working on VSCode and CodeReady to offer an alternate solution for developers.
> Please bring back the IDE-based 'Guided Rule Editor'
> ----------------------------------------------------
>
> Key: DROOLS-5454
> URL: https://issues.redhat.com/browse/DROOLS-5454
> Project: Drools
> Issue Type: Feature Request
> Components: eclipse plugin
> Affects Versions: 7.39.0.Final
> Reporter: Rick Wagner
> Assignee: Edson Tirelli
> Priority: Major
>
> JBoss Rules users have had access to an Eclipse/DevStudio plugin called the "Guided Rules Editor". It has been removed or replaced by non-IDE solutions. This is disappointing to some users who have business processes, training, etc. based around the plugin version.
>
> Please bring back the Guided Rule Editor.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (ELY-1994) Ensure the Elytron build works on Java 14
by Sonia Zaldana (Jira)
[ https://issues.redhat.com/browse/ELY-1994?page=com.atlassian.jira.plugin.... ]
Sonia Zaldana reassigned ELY-1994:
----------------------------------
Assignee: Sonia Zaldana
> Ensure the Elytron build works on Java 14
> -----------------------------------------
>
> Key: ELY-1994
> URL: https://issues.redhat.com/browse/ELY-1994
> Project: WildFly Elytron
> Issue Type: Task
> Components: Testsuite
> Reporter: Darran Lofthouse
> Assignee: Sonia Zaldana
> Priority: Major
> Fix For: 1.13.0.CR2
>
>
> Overall the build is not doing too badly and doesn't fail until we get to the main testsuite.
>
> {code:java}
> [INFO] WildFly Elytron - Tests ............................ FAILURE [ 1.447 s]
> [INFO] WildFly Elytron .................................... SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 01:46 min
> [INFO] Finished at: 2020-06-11T11:25:23+01:00
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0-jboss-1:testCompile (default-testCompile) on project wildfly-elytron-tests: Compilation failure: Compilation failure:
> [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[31,25] package java.security.acl does not exist
> [ERROR] /home/darranl/src/community/wildfly-elytron/tests/base/src/test/java/org/wildfly/security/auth/TestLoginModule.java:[107,40] cannot find symbol
> [ERROR] symbol: class Group
> [ERROR] location: class org.wildfly.security.auth.TestLoginModule
> [ERROR] -> [Help 1] {code}
> If this is all that is failing for us maybe we can revisit the test and see how appropriate it is and if it can be adapted to use available APIs.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler
by lukas brandl (Jira)
[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ]
lukas brandl commented on JGRP-2486:
------------------------------------
Thank you for the quick reply and the recommendations.
To clarify: the dead node is never suspected by the surviving node in this case.
The thread getting stuck on the bundler (or the tcp connection) isn’t a problem in itself but appears to be the reason why the the node is never suspected.
We are aware that there are newer alternatives to FD, but we can’t easily change the protocol stack if this causes incompatibility with previous versions and therefore can’t be upgraded in a rolling fashion.
> FD Monitor get stuck on TrasferQueueBundler
> -------------------------------------------
>
> Key: JGRP-2486
> URL: https://issues.redhat.com/browse/JGRP-2486
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.22
> Reporter: lukas brandl
> Assignee: Bela Ban
> Priority: Major
> Attachments: Main.java, stack-trace.txt
>
>
> Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected.
> The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5458) Project broken after test scenario run with possibly a class-loading issue
by Jozef Marko (Jira)
[ https://issues.redhat.com/browse/DROOLS-5458?page=com.atlassian.jira.plug... ]
Jozef Marko updated DROOLS-5458:
--------------------------------
Labels: drools-tools (was: )
> Project broken after test scenario run with possibly a class-loading issue
> --------------------------------------------------------------------------
>
> Key: DROOLS-5458
> URL: https://issues.redhat.com/browse/DROOLS-5458
> Project: Drools
> Issue Type: Bug
> Components: Scenario Simulation and Testing
> Affects Versions: 7.39.0.Final
> Reporter: Jan Stastny
> Assignee: Yeser Amer
> Priority: Blocker
> Labels: drools-tools
> Attachments: bpms_scesim-tickets.zip
>
>
> For a Scenario Simulation that tests DRL rule and facts having an enum property a seemingly class-loading issue occurs in Business Central.
> The ultimate error is in the DRL file validation:
> {code:java|title=DRL file}
> package org.jboss.qa.ba.scesim;
> rule "child ticket"
> when
> t: Ticket ( type==TicketType.CHILD)
> then
> t.setPrice(5.0);
> end
> {code}
> {code:java|title=Validation error}
> [KBase: defaultKieBase]: Unable to Analyse Expression type == TicketType.CHILD:
> [Error: Comparison operation requires compatible types. Found class org.jboss.qa.ba.scesim.TicketType and class org.jboss.qa.ba.scesim.TicketType]
> [Near : {... type == TicketType.CHILD ....}]
> ^
> {code}
> The issue happens in given scenario:
> # import project
> # go to DRL file and run validation - succeeds
> # go to scenario simulation and run - succeeds
> # go back to DRL file and run validation - fails with the error above
> # go to scenario simulation and run again - fails due to the rule not being evaluated for given facts
> The issue disappears when running Build of the project in the Project perspective.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ]
Bela Ban edited comment on JGRP-2486 at 6/26/20 8:08 AM:
---------------------------------------------------------
This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here?
Note that you could use {{RED}} to drop messages if the queue starts getting full...
The surviving node should suspect and exclude the dead node.
Note that I don't recommend FD, I suggest use FD_ALL2 or FD_ALL3 instead; there have been some nice improvements in the latter, e.g. skipping the sending of heartbeats if real traffoc is received etc
was (Author: belaban):
This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here?
Note that you could use {{RED}} to drop messages if the queue starts getting full...
> FD Monitor get stuck on TrasferQueueBundler
> -------------------------------------------
>
> Key: JGRP-2486
> URL: https://issues.redhat.com/browse/JGRP-2486
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.22
> Reporter: lukas brandl
> Assignee: Bela Ban
> Priority: Major
> Attachments: Main.java, stack-trace.txt
>
>
> Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected.
> The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JGRP-2486) FD Monitor get stuck on TrasferQueueBundler
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2486?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2486:
--------------------------------
This wouldn't happen if you used {{UDP}} or {{TCP_NIO2}}. Also, if you disabled the NIC, TCP itself would block after a while, so what's the use case here?
Note that you could use {{RED}} to drop messages if the queue starts getting full...
> FD Monitor get stuck on TrasferQueueBundler
> -------------------------------------------
>
> Key: JGRP-2486
> URL: https://issues.redhat.com/browse/JGRP-2486
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.22
> Reporter: lukas brandl
> Assignee: Bela Ban
> Priority: Major
> Attachments: Main.java, stack-trace.txt
>
>
> Apparently there is an issue in the FD protocol. When a cluster nodes is disconnected and the disconnect isn't handled by FD_SOCK, FD stops sending heartbeats after a while. This only happens when the queue of the TrasferQueueBundler fills up before the node is suspected.
> The stack trace shows that the FD$Monitor is blocked by the bundler. This is probably the reason why the heartbeat timeouts are not noticed.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (DROOLS-5449) ClassCastException upon unreferenced declare update
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5449?page=com.atlassian.jira.plug... ]
Mario Fusco resolved DROOLS-5449.
---------------------------------
Resolution: Explained
After a KieBase has been updated you shouldn't keep using the FactType obtained from that KieBase before the update. Getting again the FactType from the KieBase after the update, e.g. in your test case adding
{code:java}
factType = kieBase.getFactType("org.example", "ReferencedType");{code}
after the update, fixes the test.
> ClassCastException upon unreferenced declare update
> ---------------------------------------------------
>
> Key: DROOLS-5449
> URL: https://issues.redhat.com/browse/DROOLS-5449
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 7.38.0.Final
> Reporter: Matteo Casalino
> Assignee: Mario Fusco
> Priority: Major
> Attachments: class-cast-exception-on-unreferenced-declare-update.zip
>
>
> After updating a declared type that is not referenced in the rules with _updateToVersion()_,
> running _fireAllRules()_ many times in a loop throws _ClassCastException_.
> E.g., when the following DRL:
> {noformat}
> declare UnreferencedType
> x : int
> end
> declare ReferencedType
> str : String
> end
>
> rule "example rule"
> when
> ReferencedType( str == "A" )
> then
> end{noformat}
> is updated to:
> {noformat}
> declare UnreferencedType
> x : int
> newField : String
> end
> declare ReferencedType
> str : String
> end
>
> rule "example rule"
> when
> ReferencedType( str == "A" )
> then
> end{noformat}
> the following exception it thrown by _fireAllRules()_:
> {noformat}
> java.lang.RuntimeException: Error evaluating constraint 'str == "A"' in [Rule "example rule" in org/example/rules.drl]
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:277)
> at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:225)
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:139)
> ...
> Caused by: java.lang.ClassCastException: class org.example.ReferencedType cannot be cast to class org.example.ReferencedType (org.example.ReferencedType is in unnamed module of loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @46292372; org.example.ReferencedType is in unnamed module of loader org.drools.dynamic.DynamicProjectClassLoader$DefaultInternalTypesClassLoader @23b8d9f3)
> at ConditionEvaluator7ed8b2c57cad4e74b856fdba30554aa1.evaluate(Unknown Source)
> at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:275)
> ... 43 more{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years