[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on WFLY-9742:
-----------------------------------
I'm in a conference this week, so I won't get to it until next week. If you want to work up a PR that would be great.
> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
> Key: WFLY-9742
> URL: https://issues.jboss.org/browse/WFLY-9742
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Final
> Reporter: Markus Dlugi
> Assignee: David Lloyd
> Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFCORE-3563) Could not enable application deployment on two server groups in domain
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3563?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-3563:
----------------------------------------------
[~vmarek], is it a new behavior? I just checked in 3.x branch and the behavior is similar, we can't re-deploy a disabled deployment in domain mode from the command. [~mkopecky] could you confirm that 7.1 has same behavior?
> Could not enable application deployment on two server groups in domain
> ----------------------------------------------------------------------
>
> Key: WFCORE-3563
> URL: https://issues.jboss.org/browse/WFCORE-3563
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Vratislav Marek
> Assignee: Jean-Francois Denise
>
> {noformat}
> [domain@localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
> (\"server-group\" => \"other-server-group\"),
> (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
> (\"server-group\" => \"other-server-group\"),
> (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs
by Markus Dlugi (JIRA)
[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ]
Markus Dlugi commented on WFLY-9742:
------------------------------------
Alright, thanks for the quick response. That's what I thought as well, I just wasn't sure that there is no code which relies on the initial TCCL of the JBoss Threads.
I could provide a PR for this if you want? Although it's just one line of code, so it might be easier for you to do it yourself.
> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
> Key: WFLY-9742
> URL: https://issues.jboss.org/browse/WFLY-9742
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Final
> Reporter: Markus Dlugi
> Assignee: David Lloyd
> Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss Threads caused by MDBs
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.... ]
David Lloyd reassigned WFLY-9742:
---------------------------------
Assignee: David Lloyd (was: Jason Greene)
> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
> Key: WFLY-9742
> URL: https://issues.jboss.org/browse/WFLY-9742
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 11.0.0.Final
> Reporter: Markus Dlugi
> Assignee: David Lloyd
> Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob...] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-thread...] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment
by Vratislav Marek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ]
Vratislav Marek commented on WFCORE-3566:
-----------------------------------------
Should they both commands to warn or report an error?
> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
> Key: WFCORE-3566
> URL: https://issues.jboss.org/browse/WFCORE-3566
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Vratislav Marek
> Assignee: Jean-Francois Denise
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone@localhost:9990 /] deployment info
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> cli-test-another-deploy.war cli-test-another-deploy.war true true OK
> cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED
> cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK
> [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] deployment info --server-groups=main-server-group
> NAME RUNTIME-NAME STATE
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled
> cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added
> cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added
> cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled
> [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFCORE-3566) Different results of disabling commands already disabled deployment
by Vratislav Marek (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugi... ]
Vratislav Marek updated WFCORE-3566:
------------------------------------
Description:
*Different command result of disabling already disabled deployment in standalone and domain mode*
* In standalone return
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error
{noformat}
[standalone@localhost:9990 /] deployment info
NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
cli-test-another-deploy.war cli-test-another-deploy.war true true OK
cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED
cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK
[standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone@localhost:9990 /]
{noformat}
{noformat}
[domain@localhost:9990 /] deployment info --server-groups=main-server-group
NAME RUNTIME-NAME STATE
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled
cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added
cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added
cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled
[domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain@localhost:9990 /]
{noformat}
was:
*Different command result of in standalone and domain mode*
* In standalone return
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error
{noformat}
[standalone@localhost:9990 /] deployment info
NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
cli-test-another-deploy.war cli-test-another-deploy.war true true OK
cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED
cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK
[standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone@localhost:9990 /]
{noformat}
{noformat}
[domain@localhost:9990 /] deployment info --server-groups=main-server-group
NAME RUNTIME-NAME STATE
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled
cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added
cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added
cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled
[domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain@localhost:9990 /]
{noformat}
> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
> Key: WFCORE-3566
> URL: https://issues.jboss.org/browse/WFCORE-3566
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Vratislav Marek
> Assignee: Jean-Francois Denise
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone@localhost:9990 /] deployment info
> NAME RUNTIME-NAME PERSISTENT ENABLED STATUS
> cli-test-another-deploy.war cli-test-another-deploy.war true true OK
> cli-test-app1-deploy.war cli-test-app1-deploy.war true false STOPPED
> cli-test-app2-deploy.war cli-test-app2-deploy.war true true OK
> [standalone@localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone@localhost:9990 /]
> {noformat}
> {noformat}
> [domain@localhost:9990 /] deployment info --server-groups=main-server-group
> NAME RUNTIME-NAME STATE
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled
> cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added
> cli-test-app2-deploy-all.war cli-test-app2-deploy-all.war not added
> cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war enabled
> [domain@localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain@localhost:9990 /]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months
[JBoss JIRA] (WFLY-232) Deployment fails when Dependencies is empty in a jars manifest
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-232?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-232:
----------------------------------------------
Masafumi Miura <mmiura(a)redhat.com> changed the Status of [bug 1539985|https://bugzilla.redhat.com/show_bug.cgi?id=1539985] from ASSIGNED to NEW
> Deployment fails when Dependencies is empty in a jars manifest
> --------------------------------------------------------------
>
> Key: WFLY-232
> URL: https://issues.jboss.org/browse/WFLY-232
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Gábor Farkas
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha1
>
> Attachments: empty-manifest.ear
>
>
> I have a WAR, which produces the following error on deployment:
> Caused by: java.lang.IllegalArgumentException: Empty module specification
> at org.jboss.modules.ModuleIdentifier.fromString(ModuleIdentifier.java:169) [jboss-modules.jar:1.1.1.GA]
> at org.jboss.as.server.deployment.module.ManifestDependencyProcessor.deploy(ManifestDependencyProcessor.java:83) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> ... 5 more
> I found that my WAR contains a jar in WEB-INF/lib that has empty dependencies defined in its manifest. More exactly it's "Dependencies: ", so the colon is followed by a space character before the new line characters. The ManifestDependencyProcessor parses this as one dependency, the name of which is the empty string.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 3 months