August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13521) Upgrade Infinispan to 11.0.2.Final

by Paul Ferraro (Jira)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13521) Upgrade Infinispan to 11.0.3.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13521?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13521: -------------------------------- Summary: Upgrade Infinispan to 11.0.3.Final (was: Upgrade Infinispan to 11.0.2.Final) > Upgrade Infinispan to 11.0.3.Final > ---------------------------------- > > Key: WFLY-13521 > URL: https://issues.redhat.com/browse/WFLY-13521 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > [https://issues.redhat.com/projects/ISPN/versions/12342851] > [https://issues.redhat.com/projects/ISPN/versions/12346268] > [https://issues.redhat.com/projects/ISPN/versions/12346470] > [https://issues.redhat.com/projects/ISPN/versions/12346880] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[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 commented on AG-145: ------------------------------- Thank you for the fast fix :) > 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 > Fix For: 1.9 > > 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)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (AG-145) Active waiting deadlock in StampedCopyOnWriteArrayList

by Luis Barreiro (Jira)

[ https://issues.redhat.com/browse/AG-145?page=com.atlassian.jira.plugin.sy... ] Luis Barreiro resolved AG-145. ------------------------------ Fix Version/s: 1.9 Resolution: Done Thanks [~rornaz] for reporting this illusive bug! Race conditions are always hard to detect. > 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 > Fix For: 1.9 > > 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)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5086) Embedded mode sets jboss.server.content.dir incorrectly

by Bartosz Spyrko-Smietanko (Jira)

Bartosz Spyrko-Smietanko created WFCORE-5086: ------------------------------------------------ Summary: Embedded mode sets jboss.server.content.dir incorrectly Key: WFCORE-5086 URL: https://issues.redhat.com/browse/WFCORE-5086 Project: WildFly Core Issue Type: Bug Components: Embedded Reporter: Bartosz Spyrko-Smietanko Assignee: Bartosz Spyrko-Smietanko During embedded server startup some properties are set if they're not yet present, however the logic for establishing some of them is different from normal mode. On normal startup if the jboss.server.data.dir is present 'jboss.server.content.dir' property would be set to ${jboss.server.data.dir}/content [1]. In embedded scenario it is instead set to ${jboss.server.base.dir}/standalone/data/content [2]. [1] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... [2] https://github.com/wildfly/wildfly-core/blob/master/embedded/src/main/jav... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4956) EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z]

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4956?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4956: ---------------------------------- Security: (was: Security Issue) > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z] > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4956 > URL: https://issues.redhat.com/browse/WFCORE-4956 > Project: WildFly Core > Issue Type: Bug > Components: Embedded > Reporter: Kunjan Rathod > Assignee: James Perkins > Priority: Minor > Labels: CVE-2020-10718, Security, SecurityTracking, downstream_dependency, pscomponent:wildfly > > Security Tracking Issue > Do not make this issue public. > Impact: Low > Public Date: not set > Resolve Bug By: 545 calendar days from the public date > In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug. > Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB > NOTE THIS ISSUE IS CURRENTLY EMBARGOED, DO NOT MAKE PUBLIC COMMITS OR COMMENTS ABOUT THIS ISSUE. > Flaw: > ----- > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API > https://bugzilla.redhat.com/show_bug.cgi?id=1828476 > The embedded managed process API has two methods exposed as public methods which can bypass the security manager. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5040) Elytron JASPI fallback causes dependency on PicketBox

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5040?page=com.atlassian.jira.plug... ] Darran Lofthouse resolved WFCORE-5040. -------------------------------------- Resolution: Done > Elytron JASPI fallback causes dependency on PicketBox > ----------------------------------------------------- > > Key: WFCORE-5040 > URL: https://issues.redhat.com/browse/WFCORE-5040 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta4 > > > The following is logged when PicketBox is not present. > > {code:java} > 2020-07-08 17:35:19,080 TRACE [org.wildfly.extension.elytron] (ServerService Thread Pool -- 16) Unable to load default AuthConfigFactory.: java.lang.IllegalStateException: Failed to find AuthConfigFactory : org.jboss.security.auth.message.config.JBossAuthConfigFactory2020-07-08 17:35:19,080 TRACE [org.wildfly.extension.elytron] (ServerService Thread Pool -- 16) Unable to load default AuthConfigFactory.: java.lang.IllegalStateException: Failed to find AuthConfigFactory : org.jboss.security.auth.message.config.JBossAuthConfigFactory at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:227) at org.wildfly.extension.elytron.ElytronDefinition.getAuthConfigFactory(ElytronDefinition.java:405) at org.wildfly.extension.elytron.ElytronDefinition.access$700(ElytronDefinition.java:112) at org.wildfly.extension.elytron.ElytronDefinition$ElytronAdd.lambda$performBoottime$0(ElytronDefinition.java:499) at org.wildfly.extension.elytron.SecurityActions.doPrivileged(SecurityActions.java:35) at org.wildfly.extension.elytron.ElytronDefinition$ElytronAdd.performBoottime(ElytronDefinition.java:499) at org.jboss.as.controller.AbstractBoottimeAddStepHandler.performRuntime(AbstractBoottimeAddStepHandler.java:119) at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:164) at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743) at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467) at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:384) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348) at java.lang.Thread.run(Thread.java:748) at org.jboss.threads.JBossThread.run(JBossThread.java:485)Caused by: java.lang.ClassNotFoundException: org.jboss.security.auth.message.config.JBossAuthConfigFactory from [Module "org.wildfly.extension.elytron" version 13.0.0.Beta2-SNAPSHOT from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/darranl/tmp/jacc/minimal/modules,/home/darranl/tmp/jacc/minimal/modules/system/layers/base))] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) at javax.security.auth.message.config.AuthConfigFactory$LoadAction.run(AuthConfigFactory.java:571) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:211) ... 17 more {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4956) EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z]

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-4956?page=com.atlassian.jira.plug... ] James Perkins updated WFCORE-4956: ---------------------------------- Security: (was: Security Issue) > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API [eap-7.3.z] > -------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4956 > URL: https://issues.redhat.com/browse/WFCORE-4956 > Project: WildFly Core > Issue Type: Bug > Components: Embedded > Reporter: Kunjan Rathod > Assignee: James Perkins > Priority: Minor > Labels: CVE-2020-10718, Security, SecurityTracking, downstream_dependency, pscomponent:wildfly > > Security Tracking Issue > Do not make this issue public. > Impact: Low > Public Date: not set > Resolve Bug By: 545 calendar days from the public date > In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug. > Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB > NOTE THIS ISSUE IS CURRENTLY EMBARGOED, DO NOT MAKE PUBLIC COMMITS OR COMMENTS ABOUT THIS ISSUE. > Flaw: > ----- > EMBARGOED CVE-2020-10718 wildfly: exposed setting of TCCL via the EmbeddedManagedProcess API > https://bugzilla.redhat.com/show_bug.cgi?id=1828476 > The embedded managed process API has two methods exposed as public methods which can bypass the security manager. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13734: --------------------------------------------- Thanks for confirming [~smarlow], I opened WFLY-13749 to track the aforementioned changes. > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13749) Add the bean-validation Galleon layer as an optional dependency for jpa and jpa-distributed Galleon layers

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-13749: ------------------------------------------- Summary: Add the bean-validation Galleon layer as an optional dependency for jpa and jpa-distributed Galleon layers Key: WFLY-13749 URL: https://issues.redhat.com/browse/WFLY-13749 Project: WildFly Issue Type: Task Components: Build System, JPA / Hibernate Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana Bean validation is not provisioned by default by the {{jpa}} / {{jpa-distributed}} Galleon layers. Users have to add this layer to their provisioning configuration to make Bean Validation work out of the box with a JPA deployment. Adding the {{bean-validation}} Galleon layer to {{jpa}} / {{jpa-distributed}} Galleon layers will make bean validation work with a JPA application out of the box. As a result of this task: * If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, the deployment will succeed but bean validation won't work in the application code, because by default JPA uses ValidationMode.AUTO * If the user excludes the {{bean-validation}} Galleon layer from {{jpa}} / {{jpa-distributed}} Galleon layers, and configures JPA with ValidationMode.CALLBACK, the deployment will fail because the persistent provider will thrown an exception. -- 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 August 2020