[weld-issues] [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.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614242#comment-12614242
]
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 InstanceInstanceBean instanceBeanInstance;
@Inject
public AppScopedBean(InstanceInstanceBean 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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [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.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611488#comment-12611488
]
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 InstanceInstanceBean instanceBeanInstance;
@Inject
public AppScopedBean(InstanceInstanceBean 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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
