Question

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

EJB with @Startup is started when EAR 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) reinforces more clearly what’s in the docs:

• 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

Does anyone using CDI 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?

There’re also some suggestions at Is it possible to destroy a CDI scope? that I will look at, but wanted some backup on whether scoping looks like a valid reason.

Hope you can help, thanks.

Answer 1

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.