Investigation of Duplicate Deregistration Bug in Dubbo 2.7.x and Its Fix in Later Versions

Background: I am responsible for an internally developed Dubbo registry at my company. Business teams frequently reported errors when Dubbo interfaces were deregistered twice, resulting in a "instance not found" exception. Although the error only logged a message and did not affect business, I decided to investigate because repeated deregistration also prolongs application shutdown and slows rollback.

Problem Reproduction: Using the custom 2.7.3 version of Dubbo (which includes security fixes and business adaptations) I created a demo that reproduced the error. The same error occurred with the upstream 2.7.3 source, but not with version 2.7.7, confirming that duplicate deregistration is a bug in 2.7.3 that was resolved in later releases.

Solution Considerations: Upgrading Dubbo would solve the problem, but internal modifications would need to be merged into the new version, and even if upgraded, business teams might not adopt the new version quickly.

Problem Investigation

Suspecting ShutdownHook

Because I had recently studied ShutdownHook, I first suspected it. The Dubbo 2.7.3 implementation uses the DubboShutdownHook class. Tracing the code revealed that both Dubbo and Spring register a ShutdownHook, raising the question of duplicate registration.

Debugging showed that DubboShutdownHook.doDestroy is executed only once, indicating that Spring’s initialization unregisters Dubbo’s hook, leaving only Spring’s hook. The relevant code is:

public static void addApplicationContext(ApplicationContext context) {
    CONTEXTS.add(context);
    if (context instanceof ConfigurableApplicationContext) {
        ((ConfigurableApplicationContext) context).registerShutdownHook();
        DubboShutdownHook.getDubboShutdownHook().unregister();
    }
    BeanFactoryUtils.addApplicationListener(context, SHUTDOWN_HOOK_LISTENER);
}

This proved that the ShutdownHook itself was not the cause of the duplicate deregistration.

Continuing Investigation from Deregistration Stack

By setting breakpoints in the registry extension’s unregister method, two distinct call stacks were observed. The first originates from AbstractRegistryFactory.destroyAll() , which destroys all registries, and the second from destroyProtocols() , which destroys all protocols and subsequently invokes the registry’s deregistration method.

How Dubbo 2.7.7 Avoids the Issue: In the newer code, the protocol’s destroy logic sets a destroyed flag to true after the registry is destroyed. Subsequent attempts to obtain the registry return an empty instance, so the second deregistration call becomes a no‑op.

The fix was introduced in a pull request (https://github.com/apache/dubbo/pull/5450) and is present as early as Dubbo 2.7.5.

Summary

Duplicate deregistration existed in Dubbo 2.7.0‑2.7.4; it was fixed in 2.7.5, and the Zookeeper registry does not surface the error but the issue still slows shutdown.

The problem can be resolved either by upgrading Dubbo or by modifying the registry extension so that destroy is invoked only once.

Investigating even minor issues can reveal valuable knowledge, such as Dubbo’s clever handling of ShutdownHook registration.