[JBoss JIRA] (WFLY-11678) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11678?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11678:
---------------------------------
Description:
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?
was:
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?
> 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: EE
> Environment: -- EAP 7.1.4
> Reporter: Lei Yu
> Assignee: James Perkins
> Priority: Major
>
> 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)
5 years, 8 months
[JBoss JIRA] (WFLY-11678) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11678?page=com.atlassian.jira.plugin... ]
James Perkins moved JBEAP-16336 to WFLY-11678:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-11678 (was: JBEAP-16336)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: EE
(was: Class Loading)
(was: Concurrency Utilities)
Affects Version/s: (was: 7.1.4.GA)
> 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: EE
> Environment: -- EAP 7.1.4
> Reporter: Lei Yu
> Assignee: James Perkins
> Priority: Major
>
> 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)
5 years, 8 months
[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ]
Jeff Mesnil updated WFCORE-629:
-------------------------------
Fix Version/s: 8.0.0.Beta5
(was: 8.0.0.Beta4)
> Enabled automatic encryption of passwords stored in configuration
> -----------------------------------------------------------------
>
> Key: WFCORE-629
> URL: https://issues.jboss.org/browse/WFCORE-629
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Management, Security
> Environment: Wildfly 9
> Reporter: Jason Shepherd
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 8.0.0.Beta5
>
>
> Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration.
> It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3542:
--------------------------------
Fix Version/s: 8.0.0.Beta5
(was: 8.0.0.Beta4)
> Elytron JDBC realm password mapping is not consistent with underlying implementation
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-3542
> URL: https://issues.jboss.org/browse/WFCORE-3542
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: David Lloyd
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 8.0.0.Beta5
>
>
> There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.
> The problem is that the *{{salt-index}} and {{itereration-count-index}} attributes should be optional*, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFCORE-3832) Support hex encoding in jdbc-realm for elytron
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-3832?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3832:
--------------------------------
Fix Version/s: 8.0.0.Beta5
(was: 8.0.0.Beta4)
> Support hex encoding in jdbc-realm for elytron
> ----------------------------------------------
>
> Key: WFCORE-3832
> URL: https://issues.jboss.org/browse/WFCORE-3832
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 5.0.0.Alpha7
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Priority: Major
> Labels: elytron
> Fix For: 8.0.0.Beta5
>
>
> Old database login-module can be configured passing the attribute {{hashEncoding}}, for example:
> {code:xml}
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/>
> <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/>
> <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/>
> <module-option name="hashAlgorithm" value="SHA-1"/>
> <module-option name="hashEncoding" value="hex"/>
> <module-option name="hashCharset" value="UTF-8"/>
> </login-module>
> {code}
> Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron.
> Think also about the charset attribute.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months
[JBoss JIRA] (WFCORE-3947) Support SSL Certificate revocation using OCSP
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFCORE-3947?page=com.atlassian.jira.plugi... ]
Jeff Mesnil updated WFCORE-3947:
--------------------------------
Fix Version/s: 8.0.0.Beta5
(was: 8.0.0.Beta4)
> Support SSL Certificate revocation using OCSP
> ---------------------------------------------
>
> Key: WFCORE-3947
> URL: https://issues.jboss.org/browse/WFCORE-3947
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Affects Versions: 6.0.0.Alpha2
> Reporter: Jan Kalina
> Assignee: Martin Mazanek
> Priority: Critical
> Fix For: 8.0.0.Beta5
>
>
> - Provide undertow's client certificate revocation capability when undertow is used as a load balancer using OCSP.
> (CRL capability is provided in the earlier release as part of Elytron SSL Consolidation effort that this JIRA is cloned from)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 8 months