2 Replies Latest reply on Dec 12, 2011 3:20 AM by assen

    Weld CDI Application and Dependent scopes impact garbage collection?

    benkirby

      This is also on stackoverflow, but thought I would try my luck here as well...


      We're starting to experiment with implementing our backend services using CDI. The scenario is this:


      An EJB Singleton with @Startup is started when the EAR's deployed. An ApplicationScoped bean is injected onto this:



         @ApplicationScoped
          public class JobPlatform {
          
               private PooledExecutor threadHolder;
          
               @Inject @Any
               private Instance<Worker> workerSource;
          ...




           
      The bean also has an Observer method, which, when an event is observed, gets a worker bean from the Instance workerSource and puts it on the threadPool, where it eventually runs to completion.


      All working nicely. However... we've started to see garbage collection issues. A JMAP heap histogram shows that there are many of these workers hanging around, un-garbage collected.


      We believe that this is down to the combination of CDI scoping. The API page for @Dependant (http://docs.jboss.org/cdi/api/1.0-SP1/javax/enterprise/context/Dependent.html)





      • An instance of a bean with scope @Dependent injected into a field, bean constructor or initializer method is a dependent object of the bean or Java EE component class instance into which it was injected.

      • An instance of a bean with scope @Dependent injected into a producer method is a dependent object of the producer method bean instance that is being produced.

      • An instance of a bean with scope @Dependent obtained by direct invocation of an Instance is a dependent object of the instance of Instance.



      So, following this:



      • The workerSource bean is bound to JobPlatform, and therefore has an ApplicationScoped lifetime

      • Any worker beans retrieved using that instance are bound to it, and therefore have an ApplicationScoped lifetime

      • Because the beanstore of the ApplicationScoped context (my knowledge of the terminology gets a bit hazy here) still has a reference to worker beans, they're not destroyed/garbage collected



      Do you Weld users agree with this? Have you experienced this lack of garbage collection and, if so, can you suggest any workarounds?


      The workers cannot be ApplicationScoped, yet the platform has to be. If we were to create a custom WorkerScope (uh ohhh...) and annotate each worker class with it, would that be sufficient to separate the dependency between worker and instance source?


      Hope you can help, thanks.




        • 1. Re: Weld CDI Application and Dependent scopes impact garbage collection?
          benkirby

          Big thanks to Jason Porter for answering this on stackoverflow:



          Your understanding is correct. This was an oversight in the spec, and something that will be fixed in CDI 1.1. Instance can have a memory leak just like you've described when used in a long running scope such as SessionScoped or ApplicationScoped. What you will need to do is get a hold of the Contextual or Bean for the instance and destroy it that way.

          For what you're doing, and to avoid the memory leak you're best off to use the BeanManager methods to create instances (that way you'll also have a handle on the Bean and can destroy it) instead of Instance.

          • 2. Re: Weld CDI Application and Dependent scopes impact garbage collection?
            assen

            Hi,


            I have a question regarding this issue (for better understanding)


            What if you define workerSource as injectable parameter to your Observer method instead of instance variable in JobPlatform?


            Something like :


            public void onYourEvent(@Observes YourEvent event, @Any Instance<Worker> workerSource)
            {
             ...
            }
            



            Whould workerSource (and all the workers retrieved from it) be ApplicationScoped?