In which order does Weld destroy @ApplicationScoped beans?

[chrisjr]

Hi,

I have a WELD 2.3.4/Tomcat 8 application that runs in AWS; AWS "auto-scaling" means that my instances of my application will be started and stopped quite aggressively. I have therefore been examining how my application shuts itself down to ensure that nothing is lost. However, I have noticed that WELD is executing the @PreDestroy methods for some @ApplicationScoped beans while there are still other beans that are actively depending on them! I had always assumed that WELD calculated some kind of "dependency graph" internally so that it could destroy beans in some "safe" order, but this doesn't appear to be the case.

My particular application involves several @ApplicationScoped beans that are instantiated immediately by observing an @Initialized(ApplicationScoped.class) event. And then these beans are injected as dependencies into a set of @Dependent "worker" beans. (Yes, these workers are managed beans). However, when the application shuts down, I am seeing the @ApplicationScoped beans destroyed first. The worker beans' @PreDestroy methods then fail because services that they require are no longer available. I can probably construct an example application, if this is a WELD bug - although I am suspecting that it isn't really, and that WELD makes no guarantee about the order in which it invokes @PreDestroy methods. Is this correct, please?

I have noticed that I can observe a @Destroyed(ApplicationScoped.class) event, which is dispatched before any @PreDestroy methods are called. However, this observer method cannot replace a @PreDestroy method for a @Dependent scoped bean! And CDI 1.2 doesn't allow me to control the order in which @Destroyed(ApplicationScoped.class) events are received any more than it appears to for invoking @PreDestroy methods anyway.

I have currently migrated some "clean-up" work out of @PreDestroy methods and into other @ApplicationScoped beans' @Destroyed event handlers, but it does seem that I've mangled the application slightly doing this. Have I missed anything about how WELD shuts applications down, please?

Thanks,

Chris

[mkouba]

Hi Chris, you're right that the ordering is not guaranteed, in other words beans are destroyed in no particular order. The "dependency graph" is a nice idea but it wouldn't work for non-inject cases (BeanManager.getReference(), Instance.get()) and unmanaged contextual instances (or at least would bring inadequate complexity). Also the spec does not define this. However, feel free to create a feature request (either for Weld or CDI, or both ;-).

[chrisjr]

Thanks, perhaps future CDI could support something like EJB's @DependsOn annotation?

[mkouba]

From what I've heard EJB's @DependsOn is also problematic. Maybe CDI could introduce a new container lifecycle event fired before contexts are being destroyed? In fact, BeforeShutdown should be rather called AfterShutdown. But I'm afraid we're too late to the party (renaming is not possible due to backward compatibility).

[mkouba]

[CDI-601] Add container lifecycle event fired before container destroys all contexts - JBoss Issue Tracker

[chrisjr]

Hmm, I'm not sure how useful a container lifecycle event would be to me. Aren't these events inaccessible from ordinary CDI managed beans, which are the beans which I need to shutdown gracefully?

[mkouba]

You're right that it might be more practical to fire a regular event, similar to @Destroyed(X.class).

[chrisjr]

FWIW, I have managed to persuade my weld-servlet application to observe the BeforeShutdown event:

public class ShutdownExtension implements Extension {
    private static final Logger LOG = LoggerFactory.getLogger(ShutdownExtension.class);

    public void onShutdown(
        @Observes BeforeShutdown beforeShutdown,
        BeanManager beanManager
    ) {
        LOG.info("*** SHUTTING DOWN ***");
        beanManager.fireEvent(new Shutdown());
    }
}

where Shutdown is my own event object that my beans can observe. However, I've also needed to create a services file:

WEB-INF/classes/META-INF/services/javax.enterprise.inject.spi.Extension

This approach does seem overly complicated!

(This is just demonstrating that I can observe container events; as you've already mentioned, the BeforeShutdown event itself is being fired after WELD has begun to destroy my beans).