Когда я закрываю Tomcat, я наблюдаю правильное завершение работы и очистку Spring WebApplicationContext. Однако, когда я повторно развертываю свою основанную на Spring WAR (путем копирования новой WAR в webapps), нормального завершения работы не происходит. Для меня это проблема из-за всех вытекающих утечек ресурсов:

org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named [hz.hazelcast-swipe-instance.scheduled] but has failed to stop it. This is very likely to create a memory leak.
org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [] appears to have started a thread named [hz.hazelcast-swipe-instance.operation.thread-0] but has failed to stop it. This is very likely to create a memory leak.

... и многое другое. Я использую конфигурацию без XML, это мой WebApplicationInitializer:

public class WebApplicationInitializer extends AbstractAnnotationConfigDispatcherServletInitializer
{
  @Override protected Class<?>[] getRootConfigClasses() {
    return new Class[] { WebSecurityConfig.class, WebMvcConfig.class };
  }
  @Override protected Class<?>[] getServletConfigClasses() { return null; }

  @Override protected String[] getServletMappings() { return new String[] { "/" }; }

  @Override public void onStartup(ServletContext ctx) throws ServletException {
    ctx.setInitParameter("spring.profiles.active", "production");
    super.onStartup(ctx);
  }
}

Не существует специальной конфигурации для управления поведением при перезагрузке контекста сервлета, и я предполагаю, что это должно было работать из коробки.

Есть ли способ правильно закрыть WebApplicationContext перед продолжением процедуры перезагрузки контекста сервлета?

Я использую Spring 4.0.5, Tomcat 7.0.54, Hazelcast 3.2.1, Hibernate 4.3.4.Final.

Обновить

Я добавил прослушиватель приложения Spring для ContextClosedEvent и распечатал трассировку стека его вызова:

    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:333) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:335) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:880) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
    at org.springframework.context.support.AbstractApplicationContext.close(AbstractApplicationContext.java:841) [spring-context-4.0.6.RELEASE.jar:4.0.6.RELEASE]
    at org.springframework.web.servlet.FrameworkServlet.destroy(FrameworkServlet.java:819) [spring-webmvc-4.0.6.RELEASE.jar:4.0.6.RELEASE]
    at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1486) [catalina.jar:7.0.54]
    at org.apache.catalina.core.StandardWrapper.stopInternal(StandardWrapper.java:1847) [catalina.jar:7.0.54]
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) [catalina.jar:7.0.54]
    at org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5647) [catalina.jar:7.0.54]
    at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232) [catalina.jar:7.0.54]
    at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1575) [catalina.jar:7.0.54]
    at org.apache.catalina.core.ContainerBase$StopChild.call(ContainerBase.java:1564) [catalina.jar:7.0.54]

Это указывает на то, что отключение Spring происходит в его методе Servlet#destroy. Это соответствующий фрагмент из AbstractApplicationContext#close():

        if (logger.isInfoEnabled()) {
            logger.info("Closing " + this);
        }

        LiveBeansView.unregisterApplicationContext(this);

        try {
            // Publish shutdown event.
            publishEvent(new ContextClosedEvent(this));
        }
        catch (Throwable ex) {
            logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
        }
        // Stop all Lifecycle beans, to avoid delays during individual destruction.
        try {
            getLifecycleProcessor().onClose();
        }
        catch (Throwable ex) {
            logger.warn("Exception thrown from LifecycleProcessor on context close", ex);
        }

        // Destroy all cached singletons in the context's BeanFactory.
        destroyBeans();

        // Close the state of this context itself.
        closeBeanFactory();

        // Let subclasses do some final clean-up if they wish...
        onClose();

        synchronized (this.activeMonitor) {
            this.active = false;
        }

Я вижу запись в журнале с начала этого фрагмента и получаю свой ContextClosedEvent. Я также вижу запись DefaultLifecycleProcessor - Stopping beans in phase 2147483647, которая, вероятно, происходит из строки getLifecycleProcessor.onClose(). Похоже, что после этого происходит какая-то ошибка. Некоторое исключение можно проглотить.

Обновление 2

По запросу я настраиваю Hazelcast следующим образом:

@Bean(destroyMethod="shutdown") public HazelcastInstance hazelcast() {
  final Config c = hzConfig();
  final JoinConfig join = c.getNetworkConfig().getJoin();
  join.getMulticastConfig().setEnabled(false);
  join.getTcpIpConfig().setEnabled(true);
  return getOrCreateHazelcastInstance(c);
}

hzConfig() - это метод, в котором настраиваются имя экземпляра, имя группы и пароль, имена карт и индексы карт, поэтому я не думаю, что он здесь интересен.

И это моя конфигурация Hibernate SessionFactory:

@Bean
public LocalSessionFactoryBean sessionFactory() {
  final LocalSessionFactoryBean b = new LocalSessionFactoryBean();
  b.setDataSource(dataSource);
  b.setHibernateProperties(props(
      "hibernate.connection.release_mode", "on_close",
      "hibernate.id.new_generator_mappings", "true",
      "hibernate.hbm2ddl.auto", "update",
      "hibernate.order_inserts", "true",
      "hibernate.order_updates", "true",
      "hibernate.max_fetch_depth", "0",
      "hibernate.jdbc.fetch_size", "200",
      "hibernate.jdbc.batch_size", "50",
      "hibernate.jdbc.batch_versioned_data", "true",
      "hibernate.jdbc.use_streams_for_binary", "true",
      "hibernate.use_sql_comments", "true"
  ));
  return b;
}
12
Marko Topolnik 15 Июл 2014 в 17:21

4 ответа

Лучший ответ

В какой-то момент вы упомянули, что был NoClassDefFoundError для возврата. Вы исправили это, удалив эту зависимость, но затем проблема переместилась в другой класс - один из собственных классов Spring.

Это может означать, что либо одна из имеющихся у вас библиотек делает какие-то ошибки с загрузчиками классов, либо Tomcat требует инструкций, чтобы не блокировать некоторые ресурсы. См. здесь подробнее о блокируемых ресурсах Tomcat и настройке <Context>, чтобы попробовать : в вашем Tomcat conf/context.xml поместите antiResourceLocking="true" в элемент.

7
Andrei Stefan 30 Июл 2014 в 11:32

Вы пробовали увеличить unloadDelay (по умолчанию 2000 мс) для контекстов Tomcat? См. http://tomcat.apache.org/tomcat-7.0-doc/ config / context.html

ОБНОВЛЕНИЕ : я вижу, что у вас тоже проблемы с логбэком, возможно, стоит попробовать зарегистрировать и этого слушателя:

class LogbackShutdownListener implements ServletContextListener {

    @Override
    public void contextDestroyed(ServletContextEvent event) {
        LoggerContext loggerContext = (LoggerContext)LoggerFactory.getILoggerFactory();
        System.out.println("Shutting down Logback context '" + loggerContext.getName() + "' for " + contextRootFor(event));
        loggerContext.stop();
    }

    @Override
    public void contextInitialized(ServletContextEvent event) {
        System.out.println("Logback context shutdown listener registered for " + contextRootFor(event));
    }

    private String contextRootFor(ServletContextEvent event) {
        return event.getServletContext().getContextPath();
    }

}

Обязательно объявите этот прослушиватель до прослушивателя загрузчика контекста Spring, чтобы он вызывал после прослушивателя контекста при завершении работы.

ОБНОВЛЕНИЕ 2 . Также, возможно, стоит попробовать зарегистрировать другой компонент для обработки закрытия Hazelcast вручную (не забудьте также удалить destroyMethod из компонента hazelcast):

@Component
class HazelcastDestructor {

    @Autowired
    private HazelcastInstance instance;

    @PreDestroy
    public void shutdown() {
        try {
            instance.shutdown();
        } catch (Exception e) {
            System.out.println("Hazelcast failed to shutdown(): " + e);
            throw e;
        }
    }  
}

ОБНОВЛЕНИЕ 3 : просто из любопытства пробовали ли вы параллельное развертывание: http://www.javacodegeeks.com/2011/06/zero-downtime-deployment-and-rollback.html. Это может вести себя иначе, чем перезагрузка того же контекста. По крайней мере, вы должны иметь возможность лениво удалить старую версию и посмотреть, имеет ли это значение.

5
Jukka 30 Июл 2014 в 09:30

Аналогичная проблема возникает с болтающимися потоками при перезапуске контейнера здесь.

Из всех ответов один интересный ответ был дан Говардом - он показывает, как очищаются эти потоки.

Есть хорошее обсуждение и рассуждения о том, как это может прервать потоки здесь.

Теперь реализуйте ServletContextListener и позаботьтесь об этих потоках в методе contextDestroyed () как:

    public class YourListener implements ServletContextListener{
        ....
        @Override
        public void contextDestroyed(ServletContextEvent event) {
            //Call the immolate method here
        }
    }

Зарегистрируйте этого слушателя в WebApplicationInitilizer как:

     ctx.addListener(new YourListener());

Поэтому при перезапуске сервера вызывается метод contextDestroyed, который заботится обо всех этих потоках.

1
Community 23 Май 2017 в 11:58

С точки зрения разработки веб-приложений, ServletContainer может уведомлять только о начатом и до завершения процесса приложения. Он использует ServletContextListener.

Настроить ServletContextListener в web.xml

<listener>
    <listener-class>com.var.YourListener</listener-class>
</listener>

YourListener.java

public class YourListener implements ServletContextListener {

    public void contextInitialized(ServletContextEvent sce) {
        //initialization process
    }
    public void contextDestroyed(ServletContextEvent sce) {
        //destory process
    }
}   

Обновить -XML Less

Программный

@Override 
public void onStartup(ServletContext ctx) throws ServletException {

    ctx.addListener(new YourContextListener());

    ctx.setInitParameter("spring.profiles.active", "production");
    super.onStartup(ctx);
}   

Аннотации

@WebListener / @WebServletContextListener 
public class YourContextListener implements ServletContextListener {

    public void contextInitialized(ServletContextEvent servletContextEvent) {
    }

    public void contextDestroyed(ServletContextEvent servletContextEvent) {
    }
}

Обновление - ShoutDown Hook In Spring

Я никогда не использую его до разработки приложений, мы можем зарегистрировать shoutdownhook event в AbstractApplicationContext Spring. Я не уверен, что это подойдет вам или нет.

AbstractApplicationContext context = ...
context.registerShutdownHook();

Ссылка 1 Ссылка 2

1
Community 23 Май 2017 в 11:44