Hazelcast нить предотвращает TomEE от остановки

Question

Контекста

Мы хотим использовать Hazelcast в нашей реализации JCache внутри TomEE. Поскольку нам не нужна безумная производительность, на данный момент мы хотим запустить узел Hazelcast как часть нашего приложения.

Мы используем Hazelcast 3.7 и TomEE 7.0.1.

Проблема

При остановке TomEE, он жалуется на WARNING - The web application [APPLICATION_NAME] appears to have started a thread named [SOMENAME] but has failed to stop it. This is very likely to create a memory leak. несколько раз и ВМ не остановится нормально, но продолжает работать.

Обходной путь, очевидно, заключается в том, чтобы убить процесс, как только он выглядит простоя. Само собой разумеется, что это заставляет наших разработчиков и разработчиков работать с ума.

Отдельного Hazelcast узел

Чтобы исключить возможность того, что проблемы возникают из узла Hazelcast которая запускается внутри TomEE, я попытался запустить узел автономного Hazelcast и изменил наше приложение, чтобы использовать только клиент Hazelcast для подключения к указанному узлу. Поведение оставалось прежним. Насколько я могу судить по нескольким веб-поискам, клиент Hazelcast запускает также несколько потоков, чтобы общаться с узлами сервера.

Нет дубликатом Hazelcast не мешает JVM прекращать

Этот вопрос не является дубликатом Hazelcast prevents the JVM from terminating как мы полностью полагаемся на реализацию Hazelcasts JCache. Мы не обращаемся непосредственно к экземпляру Hazelcast, и поэтому мы не можем позвонить shutDownAll().

Тестовый случай

Я создал small test case on GitHub воспроизвести проблему.

Вопросы

• Можем ли мы использовать в качестве Hazelcast JCache бэкэндом в приложении Java EE?
• Что мы должны сделать, чтобы приложение могло нормально останавливаться?
• Можем ли мы также запустить узел Hazelcast как часть нашего приложения? Если нет: почему это плохая идея?

Answer 1

Hazelcast использует свои собственные темы, и они не всегда демон, вы можете гарантировать вам выключение hazelcast экземпляр (клиент или узел) через производитель, как в https://issues.apache.org/jira/browse/TOMEE-1723

Пока hazelcast не исправляет жизненный цикл его экземпляр через расширение CDI, это, вероятно, самый чистый, который вы можете сделать.

Примечание: это также выполнимо с помощью tomee внутреннего API сервера для запуска экземпляра раньше, но не требуется для большинства случаев

Answer 2

Решение

rmannibucau «s answer указал мне в правильном направлении.

Я добавил фасоль, что @Observes @Destroyed(ApplicationScoped.class) и звонки Caching.getCachingProvider().close(). Это, в свою очередь, отключает основной экземпляр Hazelcast.

Это решение также позволяет избежать прямого взаимодействия с классами Hazelcast. Зависимость может оставаться ограниченной областью runtime.

Я добавил a branch to the test case с этим решением.