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

Adam Warski (JIRA) jira-events at lists.jboss.org
Tue Jun 28 13:57:23 EDT 2011


    [ https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611607#comment-12611607 ] 

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

        


More information about the weld-issues mailing list