[weld-issues] [JBoss JIRA] Commented: (WELD-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance<>

[Pete Muir (JIRA)]

    [ 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