May 2020 - jboss-jira - Jboss List Archives

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

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-13357?page=com.atlassian.jira.plugi... ] James Perkins commented on WFLY-13357: -------------------------------------- I'm changing this to a blocker for 20.0.0.Final since it's a regression. > (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: Blocker > Fix For: 20.0.0.Final > > > 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)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-171) Don't disable local authentication for empty username and password

by Darran Lofthouse (Jira)

Darran Lofthouse created REMJMX-171: --------------------------------------- Summary: Don't disable local authentication for empty username and password Key: REMJMX-171 URL: https://issues.redhat.com/browse/REMJMX-171 Project: Remoting JMX Issue Type: Bug Components: Connection Affects Versions: 3.0.4.Final Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.5.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13496) Change the packaging of MP Health quickstart to war to enable deployment through IDEs

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13496?page=com.atlassian.jira.plugi... ] Eduardo Martins reopened WFLY-13496: ------------------------------------ > Change the packaging of MP Health quickstart to war to enable deployment through IDEs > ------------------------------------------------------------------------------------- > > Key: WFLY-13496 > URL: https://issues.redhat.com/browse/WFLY-13496 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13496) Change the packaging of MP Health quickstart to war to enable deployment through IDEs

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13496?page=com.atlassian.jira.plugi... ] Eduardo Martins resolved WFLY-13496. ------------------------------------ Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) Resolution: Done > Change the packaging of MP Health quickstart to war to enable deployment through IDEs > ------------------------------------------------------------------------------------- > > Key: WFLY-13496 > URL: https://issues.redhat.com/browse/WFLY-13496 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 20.0.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2470) JBDC_PING can face a split-brain issue when restarting a coordinator node

by Masafumi Miura (Jira)

[ https://issues.redhat.com/browse/JGRP-2470?page=com.atlassian.jira.plugin... ] Masafumi Miura commented on JGRP-2470: -------------------------------------- bq. What's the rationale for reverting JGRP-2199? If the old coord removes all information, the new one will re-insert it (actually multiple times, if configured)... The issue (two singleton clusters) happens if the old coordinator removes all information from the table *after* the new coordinator updates the table. As updating the table by the old coordinator and the new coordinator can happen in parallel, I think there's no way to avoid this possible ordering issue with the current implementation. And, if I understand correctly, the new coordinator can re-insert the updated cluster members on the view changes, but the view change does not happen (until MEGE3 heals this situation) because all nodes run as a singleton cluster. It seems that a periodic findMembers() triggered by MERGE3 can heal the singleton clusters situation. The findMembers() can insert their own node information when the table is empty. But this happens after the interval calculated by Math.max(min_interval, Util.random(max_interval) + max_interval/2) where min_interval is 10000 and max_interval is 30000 in JBoss EAP by default. And, the actual merge happens after this. So, it could take a long time to heal the singleton clusters situation. As I wrote in the private comment, I would like to propose the following two changes: - Remove calling removeAll(cluster_name) in JDBC_PING#stop() - Change remove_old_coords_on_view_change (or remove_all_data_on_view_change) to true by default I think the latter change can mitigate JGRP-2199. What do you think? > JBDC_PING can face a split-brain issue when restarting a coordinator node > ------------------------------------------------------------------------- > > Key: JGRP-2470 > URL: https://issues.redhat.com/browse/JGRP-2470 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9, 4.0.22 > Reporter: Masafumi Miura > Assignee: Radoslav Husar > Priority: Major > Fix For: 4.2.5 > > > After [the change|https://github.com/belaban/JGroups/commit/215cdb6] for JGRP-2199, JDBC_PING deletes all entries from the table during the shutdown of the coordinator node. > This behavior has a possibility to cause a split-brain when restarting a coordinator node. Because, as all entries are lost in the following scenario, the restarting node can not find any information about existing nodes from the table and does not form a cluster. > 0. node1 and node2 form a cluster. The node1 is a coordinator. > 1. Trigger a restart of the node1 > 2. The node1 removes their node information from the table > 3. The node2 becomes a new coordinator > 4. The node2 updates their node information in the table > 5. The node1 clears all entries from the table > 6. The node1 starts again > 7. The node1 does not join the existing cluster because there's no node information in the table > Note: If step 5 happens before step 4, the split-brain issue does not happen. However, as step 4 and step 5 happen on different nodes, these steps can happen in parallel. So, the order is undefined. So, for example, if the shutdown of node1 takes a long time, there's a high possibility to face this issue. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1117) New kiali operator repo

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1117?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1117. ---------------------------------- Resolution: Done All tasks are done > New kiali operator repo > ----------------------- > > Key: SWSQE-1117 > URL: https://issues.redhat.com/browse/SWSQE-1117 > Project: Kiali QE > Issue Type: Story > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Critical > Labels: infrastructure > > There is a new kiali operator repo which we need to use in our pipelines. > https://github.com/kiali/kiali-operator -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1121) Smee client and github webhooks for new operator repo (kiali-release job)

by Filip Brychta (Jira)

[ https://issues.redhat.com/browse/SWSQE-1121?page=com.atlassian.jira.plugi... ] Filip Brychta resolved SWSQE-1121. ---------------------------------- Resolution: Done Added https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/kiali-workflow/... Webhooks are configured in kiali-operator repo > Smee client and github webhooks for new operator repo (kiali-release job) > ------------------------------------------------------------------------- > > Key: SWSQE-1121 > URL: https://issues.redhat.com/browse/SWSQE-1121 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > https://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8443/job/kiali-workflow/... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13496) Change the packaging of MP Health quickstart to war to enable deployment through IDEs

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/WFLY-13496?page=com.atlassian.jira.plugi... ] Martin Stefanko updated WFLY-13496: ----------------------------------- Git Pull Request: https://github.com/wildfly/quickstart/pull/429, https://github.com/wildfly/quickstart/pull/431 (was: https://github.com/wildfly/quickstart/pull/429) > Change the packaging of MP Health quickstart to war to enable deployment through IDEs > ------------------------------------------------------------------------------------- > > Key: WFLY-13496 > URL: https://issues.redhat.com/browse/WFLY-13496 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 20.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13462) Issues in readme for microprofile-config QS

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13462?page=com.atlassian.jira.plugi... ] Eduardo Martins resolved WFLY-13462. ------------------------------------ Fix Version/s: 20.0.0.Final (was: 20.0.0.Beta1) Resolution: Done > Issues in readme for microprofile-config QS > ------------------------------------------- > > Key: WFLY-13462 > URL: https://issues.redhat.com/browse/WFLY-13462 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > Fix For: 20.0.0.Final > > > (2) Consider adding standard sections - see other (non-MP - because these were not yet tested) > * Use of the EAP_HOME and QUICKSTART_HOME Variables > * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse > * Also consider using standard sections "Build and Deploy the Quickstart" and "Access the Application" instead of "Solution" > (3) {{EAP_HOME}} is used when starting the server, but {{JBOSS_HOME}} is used later in the step-by-step instructions to refer to the same path. Consider updating the text (and code accordingly) to use one of {{ EAP_HOME}} / {{JBOSS_HOME}} throughout the quickstart. > (4) The quickstart contains arquillian tests but readme does not mention them. Please also add prerequisites for running the tests because when running them with out-of-the-box server and QS there are failures: > {code} > [ERROR] Tests run: 7, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 4.372 s <<< FAILURE! - in org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT > [ERROR] testConfigSourceReloadedValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.029 s <<< ERROR! > java.nio.file.NoSuchFileException: null/custom.properties > at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigSourceReloadedValue(MicroProfileConfigIT.java:181) > [ERROR] testConfigPropertiesValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.013 s <<< FAILURE! > org.junit.ComparisonFailure: expected:<My[PropertyFile]ConfigValue> but was:<My[EnvProp]ConfigValue> > at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigPropertiesValue(MicroProfileConfigIT.java:84) > {code} > (5) Missing section on how to undeploy the QS. Standard section {{Undeploy the Quickstart}} can be used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13462) Issues in readme for microprofile-config QS

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13462?page=com.atlassian.jira.plugi... ] Eduardo Martins reopened WFLY-13462: ------------------------------------ > Issues in readme for microprofile-config QS > ------------------------------------------- > > Key: WFLY-13462 > URL: https://issues.redhat.com/browse/WFLY-13462 > Project: WildFly > Issue Type: Bug > Components: Quickstarts > Affects Versions: 19.1.0.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Critical > Fix For: 20.0.0.Final > > > (2) Consider adding standard sections - see other (non-MP - because these were not yet tested) > * Use of the EAP_HOME and QUICKSTART_HOME Variables > * Run the Quickstart in Red Hat JBoss Developer Studio or Eclipse > * Also consider using standard sections "Build and Deploy the Quickstart" and "Access the Application" instead of "Solution" > (3) {{EAP_HOME}} is used when starting the server, but {{JBOSS_HOME}} is used later in the step-by-step instructions to refer to the same path. Consider updating the text (and code accordingly) to use one of {{ EAP_HOME}} / {{JBOSS_HOME}} throughout the quickstart. > (4) The quickstart contains arquillian tests but readme does not mention them. Please also add prerequisites for running the tests because when running them with out-of-the-box server and QS there are failures: > {code} > [ERROR] Tests run: 7, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 4.372 s <<< FAILURE! - in org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT > [ERROR] testConfigSourceReloadedValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.029 s <<< ERROR! > java.nio.file.NoSuchFileException: null/custom.properties > at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigSourceReloadedValue(MicroProfileConfigIT.java:181) > [ERROR] testConfigPropertiesValue(org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT) Time elapsed: 0.013 s <<< FAILURE! > org.junit.ComparisonFailure: expected:<My[PropertyFile]ConfigValue> but was:<My[EnvProp]ConfigValue> > at org.wildfly.quickstarts.microprofile.config.MicroProfileConfigIT.testConfigPropertiesValue(MicroProfileConfigIT.java:84) > {code} > (5) Missing section on how to undeploy the QS. Standard section {{Undeploy the Quickstart}} can be used. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2020