[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.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