[JBoss JIRA] (WFLY-11084) inter-app quickstart does not deploy (WildFly 14.0.1)
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11084?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-11084:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Jason Greene)
> inter-app quickstart does not deploy (WildFly 14.0.1)
> -----------------------------------------------------
>
> Key: WFLY-11084
> URL: https://issues.jboss.org/browse/WFLY-11084
> Project: WildFly
> Issue Type: Bug
> Reporter: Kevin Eagles
> Assignee: Bartosz Baranowski
> Priority: Minor
>
> Using Wildfly 14.0.1.Final
> When deploying inter-app-appA.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appB/BarImpl!org.jboss.as.quickstarts.interapp.shared.Bar")
> Likewise, when deploying inter-app-appB.war, Wildfly complains about the EJB lookup for:
> @ejb(lookup = "java:global/inter-app-appA/FooImpl!org.jboss.as.quickstarts.interapp.shared.Foo")
> To reproduce, from the inter-app quickstart:
> mvn install wildfly:deploy
> Can also reproduce by just doing an mvn install, then manually deploying the jar, then appA, then appB using the HAL Management Console.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Mirko Streckenbach (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Mirko Streckenbach updated JGRP-2299:
-------------------------------------
Description:
In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
was:
In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_EVENT to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_LOCK messages to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Mirko Streckenbach (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Mirko Streckenbach updated JGRP-2299:
-------------------------------------
Attachment: JGroupsExample.java
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_EVENT to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Mirko Streckenbach (Jira)
[ https://issues.jboss.org/browse/JGRP-2299?page=com.atlassian.jira.plugin.... ]
Mirko Streckenbach updated JGRP-2299:
-------------------------------------
Attachment: udp+lock.xml
> LockService does not work correctly if unlock/lock is called in immediate succession
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2299
> URL: https://issues.jboss.org/browse/JGRP-2299
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.15
> Environment: Windows 10 Oracle JDK 1.8 131
> AIX IBM Java 8
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGroupsExample.java, udp+lock.xml
>
>
> In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
> This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
> If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_EVENT to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (JGRP-2299) LockService does not work correctly if unlock/lock is called in immediate succession
by Mirko Streckenbach (Jira)
Mirko Streckenbach created JGRP-2299:
----------------------------------------
Summary: LockService does not work correctly if unlock/lock is called in immediate succession
Key: JGRP-2299
URL: https://issues.jboss.org/browse/JGRP-2299
Project: JGroups
Issue Type: Bug
Affects Versions: 4.0.15
Environment: Windows 10 Oracle JDK 1.8 131
AIX IBM Java 8
Reporter: Mirko Streckenbach
Assignee: Bela Ban
In our application we have encountered occasional cases of LockService allowing 2 processes to hold the same lock at the same time. I could reproduce this with a simple program (see atttachment) and it happens if for a lock "unlock" is called and immediately afterwards "lock". If there is a small delay (e.g. 1 second) between the two operations everything works as expected.
This can be produced with the attached program. The program does lock/unlock/lock on a lock and then tries to lock the same lock from a different JChannel and is awarded the lock. If you place a small sleep() after the unlock, everything works as expected and the parallel lock is not awarded.
If you turn on debugging you'll see no output between unlock and lock, so it looks to me like the lock is awarded without passing GRANT_EVENT to the stack. Using a conditional break point you can see that ClientLock.acquired is still true even after the unlock().
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (WFLY-10531) Wildfly leaks ActiveMQ connections
by Jiri Ondrusek (Jira)
[ https://issues.jboss.org/browse/WFLY-10531?page=com.atlassian.jira.plugin... ]
Jiri Ondrusek commented on WFLY-10531:
--------------------------------------
[~jwgmeligmeyling] I'm trying to create integration test based on reproducer from [~gunterze]. I've tested my patch manually with attached reproducer and it worked.
I'll try to find, why there is a TransactedJMSContext but it is not inTX(). (During creation of original fix, this possibility hasn't occurred to me. But technically it could probably happen - only explanation I see from short look into code, is that type could depend on session mode. Hopefully I'll find more during today)
> Wildfly leaks ActiveMQ connections
> ----------------------------------
>
> Key: WFLY-10531
> URL: https://issues.jboss.org/browse/WFLY-10531
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Final
> Environment: openjdk 8 / openjdk 9, Linux
> Reporter: Marcel Šebek
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: WFLY-10531-ear-1.0.ear, WFLY10531.zip
>
>
> After upgrading our application from wildfly 12 to 13, the app started to crash after a while (hours, days, depending on circumstances). It crashes on
> IJ000453: Unable to get managed connection for java:/JmsXA
> and other errors (it simply cannot perform all the jobs it contains). I found that when shutting down the server which has been running for a while, I can see a bunch of these messages in the log:
> WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (ServerService Thread Pool -- 117) [:::] IJ000615: Destroying active connection in pool: ActiveMQConnectionDefinition (org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection@2f37f69)
> Bascially, the longer the server was running, more of these messages are shown. I cannot find a way how to reproduce the issue. When the server runs for short time but with some load, no connection is leaked (or just one, rarely). On the other side, it leaks connections even without any particularly high load (just a few requests and @Schedule jobs) when running for longer time.
> It may also be a bug in our application, which just happen to have more serious impact with the new wildfly version.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3067:
--------------------------------
Description:
Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
h2. Acceptance tests
# User is prompted if he wants or not to apply autolayout feature
# Positioning is automatically stored after model opening
# Simple graph, no branches, starting node on left, ending node on right
# Simple graph, no branches, starting node on bottom, ending node on top
# Tree, top node in the middle of the screen, some branches to all sides
# Graph with big crossing of edges, similar to complete graph
# Large (but sparse) graph, not all nodes visible without scrolling
was:
Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
h2. Acceptance tests
# Positioning is automatically stored after model opening
# Simple graph, no branches, starting node on left, ending node on right
# Simple graph, no branches, starting node on bottom, ending node on top
# Tree, top node in the middle of the screen, some branches to all sides
# Graph with big crossing of edges, similar to complete graph
# Large (but sparse) graph, not all nodes visible without scrolling
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # User is prompted if he wants or not to apply autolayout feature
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko reassigned DROOLS-3067:
-----------------------------------
Assignee: Jozef Marko (was: Daniel José dos Santos)
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Major
> Labels: drools-tools
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3067?page=com.atlassian.jira.plugi... ]
Jozef Marko reassigned DROOLS-3067:
-----------------------------------
Assignee: Daniel José dos Santos (was: Jozef Marko)
> [DMN Designer] Automatic Layout Feature Workbench Integration
> -------------------------------------------------------------
>
> Key: DROOLS-3067
> URL: https://issues.jboss.org/browse/DROOLS-3067
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Jozef Marko
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
> h2. Acceptance tests
> # Positioning is automatically stored after model opening
> # Simple graph, no branches, starting node on left, ending node on right
> # Simple graph, no branches, starting node on bottom, ending node on top
> # Tree, top node in the middle of the screen, some branches to all sides
> # Graph with big crossing of edges, similar to complete graph
> # Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months
[JBoss JIRA] (DROOLS-3067) [DMN Designer] Automatic Layout Feature Workbench Integration
by Jozef Marko (Jira)
Jozef Marko created DROOLS-3067:
-----------------------------------
Summary: [DMN Designer] Automatic Layout Feature Workbench Integration
Key: DROOLS-3067
URL: https://issues.jboss.org/browse/DROOLS-3067
Project: Drools
Issue Type: Task
Components: DMN Editor
Reporter: Jozef Marko
Assignee: Daniel José dos Santos
Integrate the Automatic Layout feature into workbench, so during opening an imported DMN model its nodes are positioned automatically with this feature.
h2. Acceptance tests
# Positioning is automatically stored after model opening
# Simple graph, no branches, starting node on left, ending node on right
# Simple graph, no branches, starting node on bottom, ending node on top
# Tree, top node in the middle of the screen, some branches to all sides
# Graph with big crossing of edges, similar to complete graph
# Large (but sparse) graph, not all nodes visible without scrolling
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 3 months