Jboss WS и Threads

Question

Я сделал тест WebService, который запускает Thread, который записывает в файл timestamp каждые 10 секунд. У меня умышленно не существует механизма остановки потока. Теперь, если я остановлю тест WebService и даже удалю его, Thread будет жить в Jboss навсегда (требуется перезапуск JBoss). Это нормально, что JBoss не знает о потоках, созданных в контексте WebService?

В JVM, когда приложение отключается, все потоки убиты, но здесь JVM принадлежит Jboss, , который динамически загружает классы.

Это «особенность» или ошибка?

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

Answer 1

Очистка ресурсов, используемых WebService, является обязанностью самого WebService.

Tomcat поможет вам при регистрации предупреждений, когда WebService не делает это правильно (например, когда драйвер JDBC для MySQL покидает thread hanging), и это будет даже пытаться очистить ThreadLocals для вас (см также комментарии в this служебного класса) ,

В вашем случае, поскольку вы используете стороннее приложение в WebService, вы несете ответственность за очистку ресурсов, используемых сторонним приложением, когда ваш WebService отключен. Было бы неплохо, если бы JBoss мог хотя бы сообщить об утечке ресурсов, как это делает Tomcat, но это будет особенностью, а не ошибкой.

Answer 2

Я сделал тест WebService, который запускает Thread, который записывает в файл timestamp каждые 10 секунд. У меня умышленно не существует механизма остановки потока. Теперь, если я остановлю тестовый WebService и даже удалю его, Thread будет жить в Jboss навсегда (требуется перезапуск JBoss). Это нормально, что JBoss не знает о потоках, созданных в контексте WebService?

Вы не должны запускать свои собственные потоки, поэтому JBoss не будет чистить ваши вещи для вас.

См. Также why spawning threads in Java EE is discouraged (в основном относится к Enterprise Java Beans) или "Java EE specification and multi threading".

Если стороннее приложение выполняет собственную потоковую обработку, и вы не можете его изменить, это может быть не очень хорошо подходит для сервера приложений. Старый трюк для переноса старого приложения в Java EE - это управление его жизненным циклом с использованием ServletContextListener, который имеет метод init и destroy.

Если вы можете его изменить, проверьте Concurrency Utils API example на вопрос/ответ, который я связал выше, используя ExecutorService - это современный способ управления потоками, чтобы сервер знал о вашей работе.