Темы Hazelcast предотвращают остановку TomEE

Контекст

Мы хотим использовать 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 предотвращает завершение JVM , поскольку мы полностью полагаемся на реализацию JCache Hazelcasts. Мы не обращаемся к экземпляру Hazelcast напрямую, и поэтому мы не можем вызвать shutDownAll().

Контрольный пример

Я создал небольшой тестовый кейс на GitHub , чтобы воспроизвести проблему.

Вопросы

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

2 ответа


0

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

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

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

ответил Romain Manni-Bucau 22 PM00000040000000731 2016, 16:14:07
0

Решение

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

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

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

Я добавил ответвление к тесту случай с этим решением.

ответил Schroenser 23 AM000000110000001231 2016, 11:47:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132