[JBoss JIRA] Created: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
12:37 a.m.
Memory leak through the creational context of an @AppScoped bean when injecting
Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.1.Final, 1.1.0.CR3
Reporter: Adam Warski
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
New subject: [JBoss JIRA] Updated: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Adam Warski updated WELD-920:
-----------------------------
Attachment: leak-test-1.war
.war file ready to deploy
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
New subject: [JBoss JIRA] Updated: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Adam Warski updated WELD-920:
-----------------------------
Attachment: leak-test.tar.gz
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Adam Warski commented on WELD-920:
----------------------------------
plus sources
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:39 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Adam Warski commented on WELD-920:
----------------------------------
Forgot to mention that I tested on AS6 Final and AS6 Final updated with Weld 1.1.1.Final.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:19 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis commented on WELD-920:
-----------------------------------
I think this is also happening with weld-se, for example:
{code}
WeldContainer weld = new Weld().initialize();
weld.event().select(ContainerInitialized.class).fire(new ContainerInitialized());
Instance<TestBean> instance = weld.instance().select(TestBean.class);
TestBean bean = null;
for (int i = 0 ; i < 100000; i++) {
bean = instance.get();
}
{code}
See http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:21 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis edited comment on WELD-920 at 6/26/11 10:19 AM:
-------------------------------------------------------------
I think this is also happening with weld-se 1.1.1.Final, for example:
{code}
WeldContainer weld = new Weld().initialize();
weld.event().select(ContainerInitialized.class).fire(new ContainerInitialized());
Instance<TestBean> instance = weld.instance().select(TestBean.class);
TestBean bean = null;
for (int i = 0 ; i < 100000; i++) {
bean = instance.get();
}
{code}
See http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
was (Author: pgmjsd):
I think this is also happening with weld-se, for example:
{code}
WeldContainer weld = new Weld().initialize();
weld.event().select(ContainerInitialized.class).fire(new ContainerInitialized());
Instance<TestBean> instance = weld.instance().select(TestBean.class);
TestBean bean = null;
for (int i = 0 ; i < 100000; i++) {
bean = instance.get();
}
{code}
See http://sfwk.org/Community/OOMEWithAWeldSEObjectCreationBenchmark
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:50 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis commented on WELD-920:
-----------------------------------
In my case, it looks like |InstanceImpl->creationalContext->dependentInstances|
keeps growing, as does |parentDependentInstances|.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:52 a.m.
New subject: [JBoss JIRA] Issue Comment Edited: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis edited comment on WELD-920 at 6/27/11 6:50 AM:
------------------------------------------------------------
In my case, it looks like {{InstanceImpl->creationalContext->dependentInstances}}
keeps growing, as does {{parentDependentInstances}}
was (Author: pgmjsd):
In my case, it looks like |InstanceImpl->creationalContext->dependentInstances|
keeps growing, as does |parentDependentInstances|.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:26 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Pete Muir commented on WELD-920:
--------------------------------
It appears that the discussion we had about this issue has not made it to the issue :-/.
Anyway, in essence the behavior you are seeing is expected in CDI 1.0, and this is not
really an implementation bug. If you use Instance<> to create an instance of a bean,
then that instance becomes dependent on the creator, and therefore you should not expect
to see the instance discarded until the parent instance is discarded.
We can describe instances which are attached (as the CDI 1.0 spec requires) as
"managed" instances, and those which the user takes responsibility for cleaning
up themselves as "unmanaged" instances. In CDI 1.1 I would like to add support
for unmanaged instances (the impl will just hand these over and forget about them) and
also to allow the app to request an unmanaged instance is cleaned up. Please can someone
file a CDI issue for this?
Weld could certainly be more friendly and more proactively discard instances. Ideas:
1) Analyse the dependent instance graph, and if there are no @PreDestroy/@Disposer
callbacks on in the graph, do not store the dependent instance for cleanup (this would be
a good general optimization
(2) Add a config option to allow instances created from Instance to be held only as long
as the app holds a reference, and if the app doesn't hold a reference for it's
lifetime, then Weld would not do any cleanup (Weld would hold a weak ref).
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:19 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis commented on WELD-920:
-----------------------------------
That explains it then, thanks! JIRA issue: CDI-139
So in my case weld is handing me managed instances from the {{DependentContext}}. The
context hangs on to these instances so that it can later call 'destroy' lifecycle
methods on them when the context goes away, which it never does. Makes sense. However,
it might be good to point out this difference a little more clearly in the Weld docos, as
folks who are used to Guice and PicoContainer might be surprised by this.
Idea #2 sounds simple. Either way, would that be a new method on {{Instance}} or
something?
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:23 a.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Pete Muir commented on WELD-920:
--------------------------------
No new methods on instance. (2) would be a config options. For the CDI improvement it
would be some sort of explicit destroy() method on Instance I think.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:57 p.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Adam Warski commented on WELD-920:
----------------------------------
I suspected this might be the answer ;).
Anyway, first maybe the use-case. I want to integrate with a third-party framework, where
in a listener I need to invoke a method on a bean. As there's no standard
static-injection (which would be ugly anyway), the "preferred" way as I
understood is to pass an Instance<> to the listener's constructor, and then
register that listener instance with the framework. This works well when the injected bean
has e.g. request scope, but obviously doesn't work well if the bean is
dependently-scoped (and also Weld doesn't have the stateless scope, which would I
think be the proper scope for the bean I want to look up, as dependent here obviously is a
very bad replacement).
Also, at least at first sight, Instance<Something> shouldn't behave differently
depending on where it is injected? Though I understand that if you want to discard the
bean, you need to have it working as it is currently.
I think that either solution (1) or (2) would be good, and certainly a big warning in the
docs about how Instance<> works as it's really not obvious :).
Adam
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:05 p.m.
New subject: [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Joshua Davis commented on WELD-920:
-----------------------------------
Now that I understand this a little better, I like the idea of analyzing the dependent
instance graph and not tracking (managing) any instances that don't have
@PreDestroy/@Disposer methods. It _should_ be a fully transparent optimization.
+1 on putting a *big warning* in the docs about Instance<>, as this has tripped up a
bunch of people so far.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:56 a.m.
New subject: [JBoss JIRA] (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Ales Justin updated WELD-920:
-----------------------------
Fix Version/s: 2.0.0.Alpha2
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Fix For: 2.0.0.Alpha2
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:58 a.m.
New subject: [JBoss JIRA] (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Ales Justin commented on WELD-920:
----------------------------------
This requires new API, as per CDI 1.1. discussion, hence moved to 2.x.
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Fix For: 2.0.0.Alpha2
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:57 a.m.
New subject: [JBoss JIRA] (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger updated WELD-920:
---------------------------------
Fix Version/s: 2.0.0.Alpha3
(was: 2.0.0.Alpha2)
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Fix For: 2.0.0.Alpha3
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:34 a.m.
New subject: [JBoss JIRA] (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.s...
]
Jozef Hartinger resolved WELD-920.
----------------------------------
Assignee: Jozef Hartinger
Fix Version/s: (was: 2.0.0.Alpha3)
Resolution: Rejected
Rejecting as this behavior is expected. An optimization has been made as part of WELD-1076
so that only dependencies that define a @PreDestroy callback are kept within
CreationalContext. A new issue will be filed provided an explicit destruction mechanism is
introduced in CDI 1.1
Memory leak through the creational context of an @AppScoped bean when
injecting Instance<>
------------------------------------------------------------------------------------------
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes & Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Assignee: Jozef Hartinger
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the dependent-scoped bean is
injected, each time the get() method is called on the instance, even though it's not
used, a reference to it stays in the creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where each one
calls the method, more and more memory is leaked (http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy to AS6,
click the "leak" button several times, and analyze the heap dump e.g. in
JProfiler.
@ApplicationScoped
@Named("test")
public class AppScopedBean {
private Instance<InstanceBean> instanceBeanInstance;
@Inject
public AppScopedBean(Instance<InstanceBean> instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println("Leaked!");
instanceBeanInstance.get();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4607
days inactive
4943
days old
17 comments
5 participants
participants (5)
-
Adam Warski (JIRA) -
Ales Justin (JIRA)
-
Joshua Davis (JIRA)
-
Jozef Hartinger (JIRA)
-
Pete Muir (JIRA)