[JBoss JIRA] (DROOLS-4413) fireUntilHalt continues to block after session disposed
by Mario Fusco (Jira)
[ https://issues.jboss.org/browse/DROOLS-4413?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-4413:
--------------------------------
Story Points: 5
Sprint: 2019 Week 32-34
> fireUntilHalt continues to block after session disposed
> -------------------------------------------------------
>
> Key: DROOLS-4413
> URL: https://issues.jboss.org/browse/DROOLS-4413
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.25.0.Final
> Environment: Local build of 7.24.0.Final with Oracle JDK 8
> Reporter: Jesse White
> Assignee: Mario Fusco
> Priority: Major
> Attachments: WhatsWrongWithMeTest.java, halt_log.txt
>
>
> See attached test case that reproduces the problem.
> I'm expecting that a thread calling fireUntilHalt will exit after the session is halted and disposed, but it continues to block. If the code block that performs the marshalling is ignored, then the thread exists as expected.
> Stack is:
> {code:java}
> "Thread-1" #14 daemon prio=5 os_prio=0 tid=0x00007f5a7c683000 nid=0x1c028 in Object.wait() [0x00007f5acc170000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at java.lang.Object.wait(Object.java:502)
> at org.drools.core.phreak.SynchronizedPropagationList.waitOnRest(SynchronizedPropagationList.java:128)
> - locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at org.drools.core.common.DefaultAgenda$RestHandler$FireUntilHaltRestHandler.handleRest(DefaultAgenda.java:1133)
> - locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1074)
> at org.drools.core.common.DefaultAgenda.internalFireUntilHalt(DefaultAgenda.java:991)
> at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:983)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1369)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1348)
> at org.drools.compiler.integrationtests.WhatsWrongWithMeTest.lambda$canReturnWhenHalted$0(WhatsWrongWithMeTest.java:78)
> at org.drools.compiler.integrationtests.WhatsWrongWithMeTest$$Lambda$60/994541328.run(Unknown Source)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos
by Yong Deng (Jira)
[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ]
Yong Deng commented on JGRP-2364:
---------------------------------
It is just a defensive fix and the fix itself won't introduce issues. For now, I don't have case to reproduce scenario that RELEASE_LOCK_OK is never sent back. I will report the issue when that happens.
> simply lock and unlock JGroups lock repeatedly will create chaos
> ----------------------------------------------------------------
>
> Key: JGRP-2364
> URL: https://issues.jboss.org/browse/JGRP-2364
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Environment: JDK: 1.8
> JGroups: 4.1.1
> Lock: CENTRAL_LOCK
> Reporter: Yong Deng
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: LockSimpleTest.java
>
>
> I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?*
> * Current log:
> {code:java}
> 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000]
> 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A]
> 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> {code}
> * The expected log:
> {code:java}
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (WFCORE-4559) Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream)
by Martin Stefanko (Jira)
[ https://issues.jboss.org/browse/WFCORE-4559?page=com.atlassian.jira.plugi... ]
Martin Stefanko updated WFCORE-4559:
------------------------------------
Labels: downstream_dependency (was: )
> Incorrectly formatted result produced by LocalPatchOperationTarget.info(stream)
> -------------------------------------------------------------------------------
>
> Key: WFCORE-4559
> URL: https://issues.jboss.org/browse/WFCORE-4559
> Project: WildFly Core
> Issue Type: Bug
> Components: Patching
> Affects Versions: 10.0.0.Beta1
> Reporter: Oleksiy Lubyanskyy
> Assignee: Oleksiy Lubyanskyy
> Priority: Major
> Labels: downstream_dependency
> Fix For: 10.0.0.Beta2
>
>
> Addon patches are added to the wrong instance of ModelNode which breaks the CLI `patch info --verbose`. Here is how it should be fixed
> {code:java}
> diff --git a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java
> index e739c73847..4901ccc25d 100644
> --- a/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java
> +++ b/patching/src/main/java/org/jboss/as/patching/tool/PatchOperationTarget.java
> @@ -183,9 +183,10 @@ public abstract class PatchOperationTarget {
> }
> }
> if(vInfo.hasAddOns()) {
> - final ModelNode layerNode = result.get(Constants.ADD_ON);
> + final ModelNode layersNode = result.get(Constants.ADD_ON);
> for(String name : vInfo.getAddOnNames()) {
> final TargetInfo layerInfo = vInfo.getAddOnInfo(name);
> + final ModelNode layerNode = layersNode.get(name);
> layerNode.get(Constants.CUMULATIVE).set(layerInfo.getCumulativePatchID());
> final ModelNode patchesNode = layerNode.get(Constants.PATCHES).setEmptyList();
> if(!layerInfo.getPatchIDs().isEmpty()) {
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4413) fireUntilHalt continues to block after session disposed
by Jesse White (Jira)
Jesse White created DROOLS-4413:
-----------------------------------
Summary: fireUntilHalt continues to block after session disposed
Key: DROOLS-4413
URL: https://issues.jboss.org/browse/DROOLS-4413
Project: Drools
Issue Type: Bug
Affects Versions: 7.25.0.Final
Environment: Local build of 7.24.0.Final with Oracle JDK 8
Reporter: Jesse White
Assignee: Mario Fusco
Attachments: WhatsWrongWithMeTest.java, halt_log.txt
See attached test case that reproduces the problem.
I'm expecting that a thread calling fireUntilHalt will exit after the session is halted and disposed, but it continues to block. If the code block that performs the marshalling is ignored, then the thread exists as expected.
Stack is:
{code:java}
"Thread-1" #14 daemon prio=5 os_prio=0 tid=0x00007f5a7c683000 nid=0x1c028 in Object.wait() [0x00007f5acc170000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
at java.lang.Object.wait(Object.java:502)
at org.drools.core.phreak.SynchronizedPropagationList.waitOnRest(SynchronizedPropagationList.java:128)
- locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
at org.drools.core.common.DefaultAgenda$RestHandler$FireUntilHaltRestHandler.handleRest(DefaultAgenda.java:1133)
- locked <0x00000000ecfc67b0> (a org.drools.core.phreak.SynchronizedPropagationList)
at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1074)
at org.drools.core.common.DefaultAgenda.internalFireUntilHalt(DefaultAgenda.java:991)
at org.drools.core.common.DefaultAgenda.fireUntilHalt(DefaultAgenda.java:983)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1369)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireUntilHalt(StatefulKnowledgeSessionImpl.java:1348)
at org.drools.compiler.integrationtests.WhatsWrongWithMeTest.lambda$canReturnWhenHalted$0(WhatsWrongWithMeTest.java:78)
at org.drools.compiler.integrationtests.WhatsWrongWithMeTest$$Lambda$60/994541328.run(Unknown Source)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4399) KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
by Simon Dallaway (Jira)
[ https://issues.jboss.org/browse/DROOLS-4399?page=com.atlassian.jira.plugi... ]
Simon Dallaway commented on DROOLS-4399:
----------------------------------------
Hi Maciej & contributors,
Thanks for the very prompt response
I added the extra 4 jar files mentioned in the updated README using versions from https://mvnrepository.com/artifact/org.kie.server/kie-server/7.24.0.Final
narayana-jta-4.17.43.Final.jar
narayana-tomcat-1.0.0.Final.jar
jboss-transaction-api_1.2_spec-1.1.1.Final.jar
jboss-transaction-spi-7.6.0.Final.jar
This resulted in a class not found for org.jboss.logging.Logger so I added jboss-logging-3.2.0.Final.jar
At this point I hit a no such method error com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.getRegisteredXARecoveryModule() so I replaced narayana-jta-4.17.43.Final.jar with narayana-jta-5.9.5.Final.jar
I updated my xa-recovery-properties.xml file to have the following so it matches the resource name xads in the context.xml
<entry key="DB_1_DatabaseURL">java:comp/env/xads</entry>
I am now getting
ERROR [Periodic Recovery] com.arjuna.ats.internal.jdbc.IndirectRecoverableConnection.createDataSource javax.naming.NameNotFoundException: Name [comp/env/xads] is not bound in this Context. Unable to find [comp].
SEVERE [main] org.kie.server.services.impl.KieServerImpl.init Error when initializing server extension of type jBPM KIE Server extension
java.lang.RuntimeException: Unable to create EntityManagerFactory due to Unable to find jta data source under name java:comp/env/jdbc/jbpm
A simple JSP shows that xads is bound to the default InitialContext
<%
InitialContext iCtx = new InitialContext();
%>
<p><%= iCtx.lookup("java:comp/env/xads") %></p>
Outputs
ds1: url= user=sa
I've attached the latest log file for reference.
Regards,
Simon
> KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
> -------------------------------------------------------------------------
>
> Key: DROOLS-4399
> URL: https://issues.jboss.org/browse/DROOLS-4399
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.24.0.Final
> Environment: Windows 8.1 x64
> Tomcat 9.0.16
> Reporter: Simon Dallaway
> Assignee: Maciej Swiderski
> Priority: Major
> Attachments: catalina.2019-08-05.log, catalina.2019-08-06.log, context.xml, libDir.txt, server.xml, setenv.bat, tomcat-users.xml, xa-recovery-properties.xml
>
>
> Attempting to deploy KIE Server on Tomcat 9 fails with a ClassNotFoundException org.jboss.narayana.tomcat.jta.NarayanaJtaServletContextListener when trying to setup application listener
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4399) KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
by Simon Dallaway (Jira)
[ https://issues.jboss.org/browse/DROOLS-4399?page=com.atlassian.jira.plugi... ]
Simon Dallaway updated DROOLS-4399:
-----------------------------------
Attachment: catalina.2019-08-06.log
> KIE Server kie-server-7.24.0.Final-webc fails with ClassNotFoundException
> -------------------------------------------------------------------------
>
> Key: DROOLS-4399
> URL: https://issues.jboss.org/browse/DROOLS-4399
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.24.0.Final
> Environment: Windows 8.1 x64
> Tomcat 9.0.16
> Reporter: Simon Dallaway
> Assignee: Maciej Swiderski
> Priority: Major
> Attachments: catalina.2019-08-05.log, catalina.2019-08-06.log, context.xml, libDir.txt, server.xml, setenv.bat, tomcat-users.xml, xa-recovery-properties.xml
>
>
> Attempting to deploy KIE Server on Tomcat 9 fails with a ClassNotFoundException org.jboss.narayana.tomcat.jta.NarayanaJtaServletContextListener when trying to setup application listener
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4407) [DMN Designer] Search feature - Highlight the current result with colors that follow the PF standard
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4407?page=com.atlassian.jira.plugi... ]
Guilherme Gomes updated DROOLS-4407:
------------------------------------
Description:
All places (_DMN Boxed expressions editor, Guided Decision Tables editor, Guided Decision Tables graph editor, and DMN Data Types tab_) that use the search component must follow the PatternFly standard colors to highlight the cells.
Apply the infrastructure code from https://issues.jboss.org/browse/DROOLS-4406 to highlight the grid cells, and pure CSS to highlight the Data Types.
BG: #F9D67A
Stroke: #F5C12E
⚠️ Notice:
The DMN graph stay as is for now. Since nodes can have their own colors, the current highlight is enough.
was:
All places (_DMN Boxed expressions editor, Guided Decision Tables editor, Guided Decision Tables graph editor, and DMN Data Types tab_) that use the search component must follow the PatternFly standard colors to highlight the cells.
Apply the infrastructure code from https://issues.jboss.org/browse/DROOLS-4406 to highlight the grid cells, and pure CSS to highlight the Data Types.
⚠️ Notice:
The DMN graph stay as is for now. Since nodes can have their own colors, the current highlight is enough.
> [DMN Designer] Search feature - Highlight the current result with colors that follow the PF standard
> ----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-4407
> URL: https://issues.jboss.org/browse/DROOLS-4407
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Gomes
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> All places (_DMN Boxed expressions editor, Guided Decision Tables editor, Guided Decision Tables graph editor, and DMN Data Types tab_) that use the search component must follow the PatternFly standard colors to highlight the cells.
> Apply the infrastructure code from https://issues.jboss.org/browse/DROOLS-4406 to highlight the grid cells, and pure CSS to highlight the Data Types.
> BG: #F9D67A
> Stroke: #F5C12E
> ⚠️ Notice:
> The DMN graph stay as is for now. Since nodes can have their own colors, the current highlight is enough.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months
[JBoss JIRA] (DROOLS-4270) Visual design: Highlighting treatment for GDST/DMN 7.5 Find results
by Guilherme Gomes (Jira)
[ https://issues.jboss.org/browse/DROOLS-4270?page=com.atlassian.jira.plugi... ]
Guilherme Gomes commented on DROOLS-4270:
-----------------------------------------
Thank you, [~bdellasc]!
> Visual design: Highlighting treatment for GDST/DMN 7.5 Find results
> -------------------------------------------------------------------
>
> Key: DROOLS-4270
> URL: https://issues.jboss.org/browse/DROOLS-4270
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Affects Versions: 7.23.0.Final
> Reporter: Elizabeth Clayton
> Assignee: Brian Dellascio
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: Example.png, Screen Shot 2019-05-30 at 5.14.30 PM.png, guided-decision-table-find.gif
>
>
> As a user of the proposed 7.5 GDT/DMN "Find" feature, when I submit text using the find tool, I need to see the results visually highlighting in the respective canvas area.
> Find is a local search that could be performed in these areas of the application:
> * Guided Decision Table editor (tables) - text strings within "Data cells"
> * DMN graph- text strings within canvas nodes.
> * DMN boxed expressions (logic) - text strings within "Data cells"
> Requirements
> * Colors, etc for partial and whole text strings will need to be highlighted is required.
> * General recommendations regarding the usability and appearance for highlighting entire table cells and nodes.
> * Visual styles for the above if recommended.
> Considerations
> * Will not be able to leverage browser controls for Find.
> * Visual design should take into consideration the visual treatments that will be applied within these jiras: https://issues.jboss.org/browse/DROOLS-3953 and https://issues.jboss.org/browse/DROOLS-4258.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 9 months