Поддержание работы дочернего потока

Question

Я использую сервер Websphere. У меня есть сервлет, который действует как обработчик запросов. Поскольку запрос направлен на (большую часть) фоновой обработки, мне нужно просто создать поток, который будет выполнять все эти фоновые задания. Тем временем мой обработчик запросов должен вернуться после запуска этого потока. При просмотре журнала я обнаруживаю, что, как только обработчик запросов возвращается, поток фоновой обработки также, похоже, завершает свою работу, поскольку не выдает никаких сообщений журнала. Я пытался сделать фоновый поток демоном, но опять же он не оставляет никаких сообщений журнала. Разве поток процессора запросов, который запускается websphere, не остается живым в пуле потоков навсегда? В таком случае мой фоновый поток не должен продолжать работать? Даже если обработчик запросов умирает, разве не следует, что если фоновый поток является потоком демона, он должен продолжать выполняться? Просьба уточнить. Если есть какой-то недостаток в моем понимании того, как websphere управляет своими потоками. Пожалуйста, помогите мне понять это.

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

РЕДАКТИРОВАТЬ : Добавление того, что Спецификация сервлетов должно сказать по этому поводу: Каждый объект запроса действителен только в рамках метода обслуживания сервлета, или в рамках метода фильтра doFilter, если только асинхронная обработка включен для компонента, и метод startAsync вызывается по запросу объект. В случае, когда происходит асинхронная обработка, объект запроса остается действует до завершения вызывается в AsyncContext. Контейнеры обычно перерабатывают объекты запроса, чтобы избежать снижения производительности объекта запроса создание. Разработчик должен знать, что ведение ссылок на объекты запроса для которого startAsync не был вызван вне области, описанной выше, не рекомендуется, поскольку это может иметь неопределенные результаты.

Answer 1

Создание потоков в контейнере j2ee не рекомендуется, см .: Почему создание потоков в контейнере J2EE не рекомендуется?

С Websphere вы можете использовать либо Asynchronous Beans и WorkManager, либо вы можете использовать JMS и MDB для выполнения работы.

Answer 2

Разве поток процессора запросов, запущенный websphere, не остается в пуле потоков навсегда?

Большинство экземпляров ThreadPoolExecutor позволяют потокам умирать после некоторого длительного простоя. Конечно, это необязательно, и я не уверен, как websphere управляет своими рабочими потоками. Однако потоки не зависят от потоков, которые порождают их, чтобы поддерживать их. Потоки - это объекты, которые поддерживают JVM, и каждый из них независим.

В таком случае мой фоновый поток не должен продолжать работать? Даже если обработчик запросов умирает, разве не следует, что если фоновый поток является потоком демона, он должен продолжать выполняться?

Создание демона Thread служит только для информирования JVM о том, что он может выйти, если этот поток еще жив. JVM будет продолжать выполняться до тех пор, пока не завершатся все потоки, не являющиеся демонами. В вашем случае это не имеет отношения к проблеме, так как websphere не просто выйдет из системы, пока не получит команду завершить работу. В общем, создание демона Thread является полной противоположностью того, что вы хотите. Вы хотите, чтобы этот поток оживлял вашу JVM.

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

Answer 3

В прошлом я использовал Quartz для создания «неблокирующего рабочего потока» во время ответа на HTTPRequest.

Вы можете передать работу в Quartz-thread / job и вернуть ответ, а затем взаимодействовать с Quartz-thread / job во время последующих запросов.

Вы можете скачать и узнать больше о Кварцевом планировщике здесь

Вы можете упростить процесс, используя абстракцию Spring.
Для получения информации ознакомьтесь с документацией Spring по расписанию.

Надеюсь, это поможет - дайте мне знать, если вам нужно дальнейшее направление.