[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ]
Rene Böing updated AG-145:
--------------------------
Issue Type: Bug (was: Enhancement)
> Active waiting deadlock in StampedCopyOnWriteArrayList
> ------------------------------------------------------
>
> Key: AG-145
> URL: https://issues.redhat.com/browse/AG-145
> Project: Agroal
> Issue Type: Bug
> Affects Versions: 1.8
> Reporter: Rene Böing
> Assignee: Luis Barreiro
> Priority: Critical
> Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
>
>
> While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
>
> A simple reproducer in junit (fails nearly every time on my machine):
>
> {code:java}
> @Test
> public void testThis() {
> ExecutorService service = Executors.newFixedThreadPool(10);
> StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
> Object o = new Object();
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(o);
> list.add(new Object());
> List<Runnable> runnerList = new ArrayList<>(10);
> List<Future> futureList = new ArrayList<>(10);
> for (int i = 0; i < 10; i++) {
> runnerList.add(new Runnable() {
> @Override
> public void run() {
> list.remove(o);
> System.out.println("Removed success!");
> }
> });
> }
> for (Runnable r : runnerList) {
> futureList.add(service.submit(r));
> }
> for (Future r : futureList) {
> try {
> r.get(10000, TimeUnit.MILLISECONDS);
> } catch (InterruptedException e) {
> e.printStackTrace();
> } catch (ExecutionException e) {
> e.printStackTrace();
> } catch (TimeoutException e) {
> System.out.println("Seems like we have a deadlock!");
> }
> }
> }
> {code}
>
> Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
> <property name="hibernate.agroal.maxLifetime_m">60</property>
> If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
> !image-2020-07-31-08-39-28-630.png!
>
> The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
> !image-2020-07-31-08-40-41-968.png!
>
> Kind regards,
> Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13719) Error deploying EJB in WildFly when using @EJB
by Chao Wang (Jira)
Chao Wang created WFLY-13719:
--------------------------------
Summary: Error deploying EJB in WildFly when using @EJB
Key: WFLY-13719
URL: https://issues.redhat.com/browse/WFLY-13719
Project: WildFly
Issue Type: Bug
Components: EE, EJB
Affects Versions: 20.0.1.Final
Reporter: Chao Wang
Attachments: reproducer.zip
The following example does *not* get deployed on Wildfly 20.0.1.Final (since WFLY 13.0.0.Final):
~~~
public class PleaseIgnoreMeThanks
{ @EJB private NonExistentEjbExampleLocal nonExistentEjbExample; }
~~~
The issue seems to be on the @EJB annotation.
Generated error:
{code:xml}
10:19:19,025 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."ejb-in-war.war".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-in-war.war".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "ejb-in-war.war"
at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:189)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
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:1363)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0406: No EJB found with interface of type 'org.jboss.as.quickstarts.ejbTimer.NonExistentEjbExampleLocal' for binding org.jboss.as.quickstarts.ejbTimer.PleaseIgnoreMeThanks/nonExistentEjbExample
at org.jboss.as.ejb3@20.0.1.Final//org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)
at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:269)
at org.jboss.as.ee@20.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:200)
at org.jboss.as.server@12.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:182)
... 8 more
~~{code}
!moz-extension://4f9dc55f-98eb-44f6-97f9-1c9d85f3a188/icons/logo.png!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ]
Rene Böing updated AG-145:
--------------------------
Description:
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproducer in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
was:
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproduce in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
> Active waiting deadlock in StampedCopyOnWriteArrayList
> ------------------------------------------------------
>
> Key: AG-145
> URL: https://issues.redhat.com/browse/AG-145
> Project: Agroal
> Issue Type: Enhancement
> Affects Versions: 1.8
> Reporter: Rene Böing
> Assignee: Luis Barreiro
> Priority: Critical
> Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
>
>
> While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
>
> A simple reproducer in junit (fails nearly every time on my machine):
>
> {code:java}
> @Test
> public void testThis() {
> ExecutorService service = Executors.newFixedThreadPool(10);
> StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
> Object o = new Object();
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(new Object());
> list.add(o);
> list.add(new Object());
> List<Runnable> runnerList = new ArrayList<>(10);
> List<Future> futureList = new ArrayList<>(10);
> for (int i = 0; i < 10; i++) {
> runnerList.add(new Runnable() {
> @Override
> public void run() {
> list.remove(o);
> System.out.println("Removed success!");
> }
> });
> }
> for (Runnable r : runnerList) {
> futureList.add(service.submit(r));
> }
> for (Future r : futureList) {
> try {
> r.get(10000, TimeUnit.MILLISECONDS);
> } catch (InterruptedException e) {
> e.printStackTrace();
> } catch (ExecutionException e) {
> e.printStackTrace();
> } catch (TimeoutException e) {
> System.out.println("Seems like we have a deadlock!");
> }
> }
> }
> {code}
>
> Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
> <property name="hibernate.agroal.maxLifetime_m">60</property>
> If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
> !image-2020-07-31-08-39-28-630.png!
>
> The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
> !image-2020-07-31-08-40-41-968.png!
>
> Kind regards,
> Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList
by Rene Böing (Jira)
Rene Böing created AG-145:
-----------------------------
Summary: Active waiting deadlock in StampedCopyOnWriteArrayList
Key: AG-145
URL: https://issues.redhat.com/browse/AG-145
Project: Agroal
Issue Type: Enhancement
Affects Versions: 1.8
Reporter: Rene Böing
Assignee: Luis Barreiro
Attachments: image-2020-07-31-08-39-28-630.png, image-2020-07-31-08-40-41-968.png
While using agroal connection pool, we discovered some rare deadlock, which are causing 100% cpu on some threads. These deadlocks occur in the StampedCopyOnWriteArrayList class, when there is more than one thread trying to remove the same object.
A simple reproduce in junit (fails nearly every time on my machine):
{code:java}
@Test
public void testThis() {
ExecutorService service = Executors.newFixedThreadPool(10);
StampedCopyOnWriteArrayList<Object> list = new StampedCopyOnWriteArrayList<>(Object.class);
Object o = new Object();
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(new Object());
list.add(o);
list.add(new Object());
List<Runnable> runnerList = new ArrayList<>(10);
List<Future> futureList = new ArrayList<>(10);
for (int i = 0; i < 10; i++) {
runnerList.add(new Runnable() {
@Override
public void run() {
list.remove(o);
System.out.println("Removed success!");
}
});
}
for (Runnable r : runnerList) {
futureList.add(service.submit(r));
}
for (Future r : futureList) {
try {
r.get(10000, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
} catch (ExecutionException e) {
e.printStackTrace();
} catch (TimeoutException e) {
System.out.println("Seems like we have a deadlock!");
}
}
}
{code}
Originally this deadlock seems to occur, when agroal tries to flush a connection due to the config parameter
<property name="hibernate.agroal.maxLifetime_m">60</property>
If at the same time another thread using this connection calls session.close there is a possibility in the ConnectionPool.class getting called twice. The parameter goes through the following path:
!image-2020-07-31-08-39-28-630.png!
The parallel session.close call does not find a checked_out connection and tries to flush it instead, hence two Threads are getting into the deadlock situation:
!image-2020-07-31-08-40-41-968.png!
Kind regards,
Rene
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5550) Drools model compiler fails when assigning salience from a static constant
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5550?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5550:
--------------------------------
Sprint: 2020 Week 31-33 (from Jul 27)
> Drools model compiler fails when assigning salience from a static constant
> --------------------------------------------------------------------------
>
> Key: DROOLS-5550
> URL: https://issues.redhat.com/browse/DROOLS-5550
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.31.0.Final, 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final
> Reporter: Ciprian Chiru
> Assignee: Mario Fusco
> Priority: Major
>
> Given the example rule:
> {code:java}
> global java.util.Set controlSet;
> rule "will execute per each Measurement having ID color"
> salience Salience.NORMAL
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> then
> controlSet.add($colorVal);
> end{code}
> when compiling the rules, the _org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile_ throws:
> {code:java}
> Compilation failure
> [ERROR] .../target/generated-sources/drools-model-compiler/main/java/rules/Rules1b5c9512461f45df875fa525fff06227RuleMethods0.java:[28,109] no suitable method found for supply(int)
> [ERROR] method org.drools.model.DSL.<A,R>supply(org.drools.model.Variable<A>,org.drools.model.functions.Function1<A,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,R
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method org.drools.model.DSL.<A,B,R>supply(org.drools.model.Variable<A>,org.drools.model.Variable<B>,org.drools.model.functions.Function2<A,B,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) A,B,R
> [ERROR] (actual and formal argument lists differ in length)){code}
>
> The same rule works fine when the rule is not pre-compiled.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (DROOLS-5549) Drools model compilation fails when using object builders within method calls
by Mario Fusco (Jira)
[ https://issues.redhat.com/browse/DROOLS-5549?page=com.atlassian.jira.plug... ]
Mario Fusco updated DROOLS-5549:
--------------------------------
Sprint: 2020 Week 31-33 (from Jul 27)
> Drools model compilation fails when using object builders within method calls
> -----------------------------------------------------------------------------
>
> Key: DROOLS-5549
> URL: https://issues.redhat.com/browse/DROOLS-5549
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.31.0.Final, 7.32.0.Final, 7.33.0.Final, 7.34.0.Final, 7.35.0.Final, 7.36.0.Final, 7.37.0.Final, 7.38.0.Final, 7.39.0.Final, 7.40.0.Final
> Reporter: Ciprian Chiru
> Assignee: Mario Fusco
> Priority: Major
>
> Given the example rule below:
> {code:java}
> import org.example.drools.model.*;
> import java.util.Map;
> global java.util.Set controlSet;
> function String dummyFunction(Map m) {
> return "test";
> }
> rule "will execute per each Measurement having ID color"
> no-loop
> when
> Measurement( id == "color", $colorVal : val )
> $val: String() from dummyFunction(Map.entry($colorVal))
> then
> controlSet.add($colorVal);
> end{code}
>
> compiling the rule with kie-maven-plugin, it throws the error:
> {code:java}
> ...target/generated-sources/drools-model-compiler/main/java/rules/Rules57a04348fad44377b9eacd9bb5741999RuleMethods0.java:[30,117] cannot find symbol
> [ERROR] symbol: variable $colorVal
> [ERROR] location: class rules.Rules57a04348fad44377b9eacd9bb5741999RuleMethods0{code}
>
> Same code works fine if the rules are not pre-compiled.
>
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13718) Update quick start references to "Red Hat Developer Studio" to new name "Red Hat CodeReady Studio"
by Eduardo Martins (Jira)
[ https://issues.redhat.com/browse/WFLY-13718?page=com.atlassian.jira.plugi... ]
Eduardo Martins updated WFLY-13718:
-----------------------------------
Description: Red Hat Developer Studio has been renamed to Red Hat Code Ready Studio. We need to update the quickstart documentation. (was: Red Hat Developer Studio has been renamed to Red Hat Code Ready Studio. Naming has been updated in the EAP documentation repository. We need to update the quickstart documentation as well.
One instance has a broken link. It looks like an unresolved attribute, but should be investigated.)
> Update quick start references to "Red Hat Developer Studio" to new name "Red Hat CodeReady Studio"
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-13718
> URL: https://issues.redhat.com/browse/WFLY-13718
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
> Priority: Minor
>
> Red Hat Developer Studio has been renamed to Red Hat Code Ready Studio. We need to update the quickstart documentation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 5 months