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

    Weld CDI Application and Dependent scopes impact garbage collection?

    Ben Kirby Newbie

      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:

          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.