[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611472#comment-12611472
]
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
_______________________________________________
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
