Spring+STOMP WAR包服务器启停时Bean停止失败问题求助

Hey there, let's break down why you're seeing hundreds of "Failed to Stop Bean" errors when shutting down or restarting your Spring + STOMP WAR app, and how to fix it. Based on your description of the accountEventPublisher bean, static CommService, and event handling setup, here are the most likely causes and solutions:

1. Static Class Holding Spring Bean References (Resource Leak) #

The biggest red flag here is your static CommService using the accountEventPublisher bean. Spring manages bean lifecycles, but static references exist outside the container's control. When the container tries to destroy accountEventPublisher on shutdown, if the static CommService still holds a reference to it, the bean can't be properly cleaned up—especially if it's tied to STOMP connections or event queues.

Fixes: #

• Ditch the static class: Convert CommService to a Spring-managed bean (add @Component or @Service) and inject accountEventPublisher via constructor injection. This lets Spring handle its lifecycle alongside other beans:

  @Service
  public class CommService {
      private final AccountEventPublisher accountEventPublisher;
  
      @Autowired
      public CommService(AccountEventPublisher accountEventPublisher) {
          this.accountEventPublisher = accountEventPublisher;
      }
  
      public void sendAccountEvent(AccountTrEvent event) {
          accountEventPublisher.publishEvent(event);
      }
  }
  

• If static is non-negotiable: Add a cleanup hook to clear the static reference when the container shuts down. Modify accountEventPublisher with a @PreDestroy method:

  @Component
  public class AccountEventPublisher implements ApplicationEventPublisherAware {
      private ApplicationEventPublisher appEventPublisher;
  
      // Assume your static CommService has a setter for the publisher
      @Override
      public void setApplicationEventPublisher(ApplicationEventPublisher publisher) {
          this.appEventPublisher = publisher;
          CommService.setAccountEventPublisher(this);
      }
  
      @PreDestroy
      public void cleanUpStaticReference() {
          CommService.setAccountEventPublisher(null);
      }
  }
  

2. Unfinished Event Processing on Shutdown #

If your accountEventPublisher uses async event publishing (e.g., with @Async) or your event interceptors run long-running tasks, the container might try to destroy the bean before all events are processed. This leads to failed shutdown attempts as the bean is still tied to active tasks.

Fixes: #

• Configure async task pools for graceful shutdown: If you're using @Async, customize your TaskExecutor to wait for tasks to complete on shutdown:

  @Configuration
  @EnableAsync
  public class AsyncConfig implements AsyncConfigurer {
      @Override
      public Executor getAsyncExecutor() {
          ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
          executor.setCorePoolSize(5);
          executor.setMaxPoolSize(10);
          executor.setQueueCapacity(25);
          // Wait for tasks to finish before shutting down
          executor.setWaitForTasksToCompleteOnShutdown(true);
          executor.setAwaitTerminationSeconds(10);
          executor.initialize();
          return executor;
      }
  }
  

• Add interrupt support to event handlers: Ensure your event interceptors can be interrupted during shutdown. Check for thread interrupt status in long-running logic:

  @Component
  public class AccountEventListener implements ApplicationListener<AccountTrEvent> {
      @Override
      public void onApplicationEvent(AccountTrEvent event) {
          while (/* long-running task condition */) {
              if (Thread.currentThread().isInterrupted()) {
                  // Clean up resources and exit
                  return;
              }
              // Continue processing logic
          }
      }
  }
  

3. Unreleased STOMP Resources #

Since your app uses STOMP, accountEventPublisher might be holding active STOMP sessions or connections. If these aren't closed explicitly on shutdown, Spring can't destroy the bean cleanly.

Fixes: #

• Explicitly close STOMP resources in @PreDestroy: Modify accountEventPublisher to shut down STOMP connections when the bean is destroyed:

  @Component
  public class AccountEventPublisher {
      private StompSession stompSession;
      // ... other fields and event publishing methods
  
      @PreDestroy
      public void closeStompResources() {
          if (stompSession != null && stompSession.isConnected()) {
              stompSession.disconnect();
          }
      }
  }
  

• Verify STOMP client lifecycle: Ensure your STOMP client is managed by Spring (e.g., defined as a @Bean) so its lifecycle is tied to the container's shutdown process.

4. Bean Destruction Order Conflicts #

Spring doesn't guarantee a specific bean destruction order by default. If a bean that depends on accountEventPublisher is destroyed after it, or vice versa, you might get errors when the publisher tries to interact with already-destroyed beans.

Fixes: #

• Define explicit destruction order with @DependsOn: Use the annotation to ensure dependent beans are destroyed before accountEventPublisher:

  @Component
  @DependsOn("accountEventListener")
  public class AccountEventPublisher {
      // ... bean logic
  }
  

• Check error logs for specific bean details: Look closely at the "Failed to Stop Bean" stack traces—they should name the problematic bean. Use this to map dependencies and adjust the destruction order accordingly.

内容的提问来源于stack exchange，提问作者locus2k