CODEWITHSUNDEEP
garbage-collectionscopecdijboss-weld
Ben Kirby
Ben Kirby

Reputation: 924

CDI Application and Dependent scopes can conspire to impact garbage collection?

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:

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.

Upvotes: 17

Views: 5671

Answers (2)

Ben Kirby
Ben Kirby

Reputation: 924

While looking into implementing Jason's suggested workaround, I found some more resources relating to the issue:

The issue: https://issues.jboss.org/browse/CDI-139 and https://issues.jboss.org/browse/WELD-920

Example beanManager operations: https://issues.jboss.org/browse/CDI-14?focusedCommentId=12601344&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12601344

or org.jboss.seam.faces.util.BeanManagerUtils

Upvotes: 2

LightGuard
LightGuard

Reputation: 5378

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.

Upvotes: 10

Related Questions