February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11678) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11678?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11678: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks > ------------------------------------------------------------------------------------------- > > Key: WFLY-11678 > URL: https://issues.jboss.org/browse/WFLY-11678 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Environment: -- EAP 7.1.4 > Reporter: Lei Yu > Assignee: James Perkins > Priority: Critical > Fix For: 16.0.0.CR1 > > > managed executor: > {code} > <managed-executor-services> > <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/> > </managed-executor-services> > {code} > With each undeploy, the application classloader is leaked and not released because contextClassLoader references persisted on the executor threads: > {code} > Class Name | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread @ 0xc3677570 EE-ManagedExecutorService-default-Thread-13 Thread| 1 | 160 | 88 | 1,344 > '- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0xc32b9d98 | 1 | 88 | 88 | 366,800 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > {code} > Tracing with byteman, what's strange is that it sets the app classloader on setup: > {code} > Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader > java.lang.Thread.setContextClassLoader(Thread.java:1477) > org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272) > org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderSetupContextHandle.setup(ClassLoaderContextHandleFactory.java:83) > org.jboss.as.ee.concurrent.ConcurrentContext$ChainedSetupContextHandle.setup(ConcurrentContext.java:166) > org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.setup(DefaultContextSetupProviderImpl.java:58) > org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.setupContext(ManagedFutureTask.java:121) > org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.beforeExecute(ManagedThreadPoolExecutor.java:109) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > {code} > And still sets that app classloader after task execution in the reset: > {code} > Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader > java.lang.Thread.setContextClassLoader(Thread.java:1477) > org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272) > org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderResetContextHandle.reset(ClassLoaderContextHandleFactory.java:113) > org.jboss.as.ee.concurrent.ConcurrentContext$ChainedResetContextHandle.reset(ConcurrentContext.java:284) > org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.reset(DefaultContextSetupProviderImpl.java:63) > org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.resetContext(ManagedFutureTask.java:134) > org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.afterExecute(ManagedThreadPoolExecutor.java:90) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > java.lang.Thread.run(Thread.java:748) > {code} > So the thread is sitting in the pool with the app classloader. Is there some way we should be able to get the context loader cleared or unset from the app loader in the reset? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11648) Upgrade to RESTEasy 3.6.3.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11648?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11648: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Upgrade to RESTEasy 3.6.3.Final > ------------------------------- > > Key: WFLY-11648 > URL: https://issues.jboss.org/browse/WFLY-11648 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Marek Kopecký > Assignee: Alessio Soldano > Priority: Critical > Fix For: 16.0.0.CR1 > > > Upgrade to RESTEasy 3.6.3.Final > cc [~jbliznak], [~tterem] -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11569) Port EESecurityAuthMechanismTestCase to WildFly Elytron

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11569?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11569: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Port EESecurityAuthMechanismTestCase to WildFly Elytron > ------------------------------------------------------- > > Key: WFLY-11569 > URL: https://issues.jboss.org/browse/WFLY-11569 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 16.0.0.CR1 > > > Also ensure it passes with the security manager enabled. > Also see WFLY-11348 which is the failure with PicketBox. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11542) Update Undertow ApplicationSecurityDomain to use individual factories.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11542?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11542: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Update Undertow ApplicationSecurityDomain to use individual factories. > ---------------------------------------------------------------------- > > Key: WFLY-11542 > URL: https://issues.jboss.org/browse/WFLY-11542 > Project: WildFly > Issue Type: Task > Components: Security, Web (Undertow) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 16.0.0.CR1 > > > This is to move away from the deprecated 'org.wildfly.security.http.impl.ServerMechanismFactoryImpl' which will be removed soon as it was never public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11540) Update Maven dependencies to reference individual Elytron modules.

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11540?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11540: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Update Maven dependencies to reference individual Elytron modules. > ------------------------------------------------------------------ > > Key: WFLY-11540 > URL: https://issues.jboss.org/browse/WFLY-11540 > Project: WildFly > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 16.0.0.CR1 > > > This should also review the classes the application server users as we will likely want to start considering these public API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11694) Add missing JGroups subsystem transformer tests for EAP 7.2

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11694?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11694: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Add missing JGroups subsystem transformer tests for EAP 7.2 > ----------------------------------------------------------- > > Key: WFLY-11694 > URL: https://issues.jboss.org/browse/WFLY-11694 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 15.0.1.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Major > Fix For: 16.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11693) Add missing Infinispan subsystem transformer tests for EAP 7.2

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11693?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11693: ------------------------------------ Fix Version/s: 16.0.0.CR1 (was: 16.0.0.Beta1) > Add missing Infinispan subsystem transformer tests for EAP 7.2 > -------------------------------------------------------------- > > Key: WFLY-11693 > URL: https://issues.jboss.org/browse/WFLY-11693 > Project: WildFly > Issue Type: Task > Components: Clustering > Affects Versions: 15.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > Fix For: 16.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11408) Upgrade HAL to 3.1.2.Final

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11408?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11408: ------------------------------------ Fix Version/s: 16.0.0.Beta1 (was: 16.0.0.CR1) > Upgrade HAL to 3.1.2.Final > -------------------------- > > Key: WFLY-11408 > URL: https://issues.jboss.org/browse/WFLY-11408 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Blocker > Fix For: 16.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10638) Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-10638?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFLY-10638. ------------------------------- > Eliminate "Transactional caches are not supported." log warning from ORM 5.3.* deployments > ------------------------------------------------------------------------------------------ > > Key: WFLY-10638 > URL: https://issues.jboss.org/browse/WFLY-10638 > Project: WildFly > Issue Type: Task > Components: Clustering, JPA / Hibernate > Affects Versions: 13.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Fix For: 15.0.0.Beta1, 15.0.0.Final > > > Currently, during deployment of ORM 5.3.* applications, the following warning is logged in the server console, four times per persistence unit. It should not appear at all. > {quote} > HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset. > {quote} > The warning comes from ORM 5.3 integration code org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11436) HA also needs fix for "Transactional caches are not supported." log warning from ORM 5.3.* deployments

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-11436?page=com.atlassian.jira.plugin... ] Scott Marlow closed WFLY-11436. ------------------------------- > HA also needs fix for "Transactional caches are not supported." log warning from ORM 5.3.* deployments > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-11436 > URL: https://issues.jboss.org/browse/WFLY-11436 > Project: WildFly > Issue Type: Task > Components: Clustering, JPA / Hibernate > Affects Versions: 13.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Fix For: 16.0.0.Beta1 > > > Currently, during deployment of ORM 5.3.* applications, the following warning is logged in the server console, four times per persistence unit. It should not appear at all. > {quote} > HHH025030: Transactional caches are not supported. The configuration option will be ignored; please unset. > {quote} > The warning comes from ORM 5.3 integration code org.infinispan.hibernate.cache.v53.InfinispanRegionFactory#unsetTransactions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 3 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 February 2019