Сервлеты не должны запускать потоки из-за проблем, которые могут возникнуть при кластеризации .... какие проблемы?

Question

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

Но кроме описанной выше ситуации "невозможно отключить", может быть и другая причина, по которой сервлет не может запускать потоки.Я видел некоторые упоминания о том, что если окружение кластеризовано, это вызовет проблемы.Но нет никакого реального прохождения того, что могло бы случиться, что было бы ПЛОХО.

РЕДАКТИРОВАТЬ: Это в настоящее время делается в сервлете, и у меня возникают проблемы с убеждением автора этого кода, что это не очень хорошая идея.Аргумент, что нужно понимать сложность, не сработает ... Я ищу один конкретный конкретный случай, когда может произойти что-то плохое, без намерения

В моей ситуации: рассматриваемый сервлет запускаетсяn потоков, и это происходит в каждом VM на кластере по замыслу.Нет транзакционного требования

Answer 1

Из официального FAQ :

Почему создание потоков и управление ими запрещены

Спецификация EJB присваивает EJB контейнер ответственность за управление потоками. Разрешающее предприятие экземпляры bean для создания и управления темы будут мешать способность контейнера контролировать его жизненный цикл компонентов. Нить управление не является бизнес-функцией, это деталь реализации, и это как правило, сложный и платформы. Позволяя Контейнер управления потоками снимает корпоративный бин разработчик дилинга с вопросами потоков. Многопоточный приложения все еще возможны, но управление многопоточностью находится в контейнере, а не в корпоративный бин.

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

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

Кроме того, если вам нужен одиночный фоновый поток в кластерной среде, он становится сложным.

И, наконец, приложение. Сервер контролирует транзакций . Если вы создаете потоки самостоятельно, вы должны позаботиться о том, чтобы понять все детали того, что можно использовать безопасно или нет (например, получить соединение из пула) и как использовать UserTransaction при необходимости. Идея в том, что вам не стоит беспокоиться о таких деталях, если вы используете приложение. сервер, но вам понадобится, если вы сами начнете работать с потоками.

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

Answer 2

Есть много проблем, в зависимости от вашего варианта использования.Что, если конкретный сервер в кластере, на котором работает ваш поток / задание, аварийно завершает работу, что приводит к потере вашего потока, это будет плохо?Кто-то должен быть уведомлен?Должно ли задание перейти на другой сервер в кластере?Должен ли он перезагрузиться, как только сервер снова запустится?Все это вы должны реализовать в своем потоке .... или вы можете использовать JMS, которая будет даже работать в Tomcat, с надстройкой ActiveMQ или каким-либо другим контейнером сообщений по вашему выбору, и просто написать кодэто выполняет вашу логику, и пусть контейнер беспокоится обо всем остальном.YMMV