April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13357) (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] Cheng Fang moved JBERET-492 to WFLY-13357: ------------------------------------------ Project: WildFly (was: JBeret) Key: WFLY-13357 (was: JBERET-492) Component/s: Batch (was: jberet-core) Affects Version/s: 19.0.0.Final (was: 1.3.3.Final) > (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock > ------------------------------------------------------------------------------------------ > > Key: WFLY-13357 > URL: https://issues.redhat.com/browse/WFLY-13357 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 19.0.0.Final > Reporter: Felix König > Priority: Major > > Hello, > the issue described in JBERET-180 seems to have reappeared. I am running Wildfly 16 with jberet-1.3.3. Given that there is a default batch-thread count of 10 I was able to produce a deadlock by starting 10 instances of a partitioned job simultaneously. None of the job runs fast enough to finish before all 10 jobs have been started. All 10 Batch-threads are stuck here: > {code} > "Batch Thread - 1@33537" prio=5 tid=0x109 nid=NA waiting > java.lang.Thread.State: WAITING > at jdk.internal.misc.Unsafe.park(Unknown Source:-1) > at java.util.concurrent.locks.LockSupport.park(Unknown Source:-1) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source:-1) > at java.util.concurrent.ArrayBlockingQueue.take(Unknown Source:-1) > at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:350) > at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222) > at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144) > at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) > at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) > at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60) > at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494) > at org.jberet.spi.JobExecutor$2.run(JobExecutor.java:149) > at org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source:-1) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source:-1) > at java.lang.Thread.run(Unknown Source:-1) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > which is this line of code: > {code:java} > completedPartitionThreads.take(); > {code} > Rarely some threads also get stuck at line 364 instead, which is > {code:java} > final Serializable data = collectorDataQueue.take(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13357) (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] Cheng Fang reassigned WFLY-13357: --------------------------------- Assignee: Cheng Fang > (Regression) Execution of concurrent batch jobs containg partitioned steps causes deadlock > ------------------------------------------------------------------------------------------ > > Key: WFLY-13357 > URL: https://issues.redhat.com/browse/WFLY-13357 > Project: WildFly > Issue Type: Bug > Components: Batch > Affects Versions: 19.0.0.Final > Reporter: Felix König > Assignee: Cheng Fang > Priority: Major > > Hello, > the issue described in JBERET-180 seems to have reappeared. I am running Wildfly 16 with jberet-1.3.3. Given that there is a default batch-thread count of 10 I was able to produce a deadlock by starting 10 instances of a partitioned job simultaneously. None of the job runs fast enough to finish before all 10 jobs have been started. All 10 Batch-threads are stuck here: > {code} > "Batch Thread - 1@33537" prio=5 tid=0x109 nid=NA waiting > java.lang.Thread.State: WAITING > at jdk.internal.misc.Unsafe.park(Unknown Source:-1) > at java.util.concurrent.locks.LockSupport.park(Unknown Source:-1) > at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source:-1) > at java.util.concurrent.ArrayBlockingQueue.take(Unknown Source:-1) > at org.jberet.runtime.runner.StepExecutionRunner.beginPartition(StepExecutionRunner.java:350) > at org.jberet.runtime.runner.StepExecutionRunner.runBatchletOrChunk(StepExecutionRunner.java:222) > at org.jberet.runtime.runner.StepExecutionRunner.run(StepExecutionRunner.java:144) > at org.jberet.runtime.runner.CompositeExecutionRunner.runStep(CompositeExecutionRunner.java:164) > at org.jberet.runtime.runner.CompositeExecutionRunner.runFromHeadOrRestartPoint(CompositeExecutionRunner.java:88) > at org.jberet.runtime.runner.JobExecutionRunner.run(JobExecutionRunner.java:60) > at org.wildfly.extension.batch.jberet.deployment.BatchEnvironmentService$WildFlyBatchEnvironment$1.run(BatchEnvironmentService.java:180) > at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:494) > at org.jberet.spi.JobExecutor$2.run(JobExecutor.java:149) > at org.jberet.spi.JobExecutor$1.run(JobExecutor.java:99) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source:-1) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source:-1) > at java.lang.Thread.run(Unknown Source:-1) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > {code} > which is this line of code: > {code:java} > completedPartitionThreads.take(); > {code} > Rarely some threads also get stuck at line 364 instead, which is > {code:java} > final Serializable data = collectorDataQueue.take(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13356) Add a Galleon layer for Webservices

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13356: --------------------------------------- Summary: Add a Galleon layer for Webservices Key: WFLY-13356 URL: https://issues.redhat.com/browse/WFLY-13356 Project: WildFly Issue Type: Feature Request Components: Build System, Web Services Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13355) Add a Galleon layer for EE Concurrency

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13355: --------------------------------------- Summary: Add a Galleon layer for EE Concurrency Key: WFLY-13355 URL: https://issues.redhat.com/browse/WFLY-13355 Project: WildFly Issue Type: Feature Request Components: Build System, Concurrency Utilities Reporter: Brian Stansberry Assignee: Brian Stansberry Minor thing. The existing 'ee' layer adds the EE Concurrency resources, which is fine. Adding a layer specific to ee-concurrency, which the existing ee layer would optionally depend on, would allow users to *exclude* it. Doing so wouldn't do much in terms of disk footprint, probably well under 200K. The main reason I file this is when I provision some slim servers suddenly the amount of config going to the ee concurrency resources jumps out at you. Even if the real impact of those isn't much it gives a sense of bloat. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13354) Add Galleon layers for the EJB subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13354: --------------------------------------- Summary: Add Galleon layers for the EJB subsystem Key: WFLY-13354 URL: https://issues.redhat.com/browse/WFLY-13354 Project: WildFly Issue Type: Feature Request Components: Build System, EJB Reporter: Brian Stansberry Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13352) Add a Galleon layer for the sar subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13352: --------------------------------------- Summary: Add a Galleon layer for the sar subsystem Key: WFLY-13352 URL: https://issues.redhat.com/browse/WFLY-13352 Project: WildFly Issue Type: Feature Request Components: Build System, JMX Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13353) Add a Galleon layer for the POJO subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13353: --------------------------------------- Summary: Add a Galleon layer for the POJO subsystem Key: WFLY-13353 URL: https://issues.redhat.com/browse/WFLY-13353 Project: WildFly Issue Type: Feature Request Components: Build System, POJO Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13352) Add a Galleon layer for the sar subsystem

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13352?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13352: ------------------------------------ Priority: Minor (was: Major) > Add a Galleon layer for the sar subsystem > ----------------------------------------- > > Key: WFLY-13352 > URL: https://issues.redhat.com/browse/WFLY-13352 > Project: WildFly > Issue Type: Feature Request > Components: Build System, JMX > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > Fix For: 20.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13351) Add a Galleon layer for the Mail subsystem

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13351: --------------------------------------- Summary: Add a Galleon layer for the Mail subsystem Key: WFLY-13351 URL: https://issues.redhat.com/browse/WFLY-13351 Project: WildFly Issue Type: Feature Request Components: Build System, Mail Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13350) Add a Galleon layer for JSF

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13350: --------------------------------------- Summary: Add a Galleon layer for JSF Key: WFLY-13350 URL: https://issues.redhat.com/browse/WFLY-13350 Project: WildFly Issue Type: Feature Request Components: Build System, JSF Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Beta1 Create a Galleon layer to provision the JSF subsystem. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020