Метод для обработки "убитых" заданий Java?

Question

Наше серверное веб-приложение будет обрабатывать задания, запрошенные запросами REST API.

В идеале, если сервер умирает во время выполнения задания (т. Е. При отключенном подключении), задание должно возобновляться или перезапускаться при запуске.

Очень удобный способ обработки этих заданий заключается в отдельном потоке, использующем некоторые параллельные служебные классы в Java 5. Единственная проблема заключается в том, что в случае сбоя необходимо записать детали задания и создать процесс, который читает эти данные при запуске и возобновляет работу. Это похоже на боль.

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

Есть ли лучшие подходы к этому сценарию?

Answer 1

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

например. клиент делает запрос. Если это вернет результат, все хорошо. Однако, если клиент обнаруживает, что сервер завершил работу (через преждевременное отключение HTTP-соединения), он может вернуться назад и повторить попытку позже. При желании вы можете реализовать различные стратегии повторов (например, повтор на другом хосте, отказаться от повторных попыток и т. Д.).

Таким образом, клиенты получают знания о том, что им требуется (как они должны делать в любом случае, по-видимому), а ваши серверы не сохраняют состояния, что намного проще в управлении.

Answer 2

Я бы использовал Кварц (который имеет функции переключения при отказе) для управления вашими заданиями.

PS: Я бы предпочел ошибаться, но, прочитав ваши последние вопросы, я чувствую, что вы создаете что-то слишком сложное или концептуально неправильное. ИМХО слишком много архитектурных запахов.