Может ли основной поток заканчиваться в веб-службе RESTful, пока рабочий поток продолжается?

Question

У меня есть веб-служба Java RESTful, которая будет вызываться примерно каждые 10 секунд другим процессом.Если условия правильные, веб-сервису необходимо выполнить потенциально длительный процесс ETL (скажем, 10-20 секунд).Однако мы хотим сразу же вернуться к вызывающему приложению, указав, что полезная нагрузка успешно доставлена ​​в веб-службу.

Сводка требований:

• Проверка параметров аутентификации и ввода.
• Если проверка не пройдена, вернуть ошибку в XML.
• Запустить поток, выполняющий процесс ETL.Процесс будет продолжаться только при определенных условиях.
• Возвратите XML, указывающий на доставленную полезную нагрузку и подтвержденную введенную информацию.

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

Кто-нибудь хочет указать мне лучший способ сделать это?

Answer 1

это совершенно правильный способ сделать это. что "кажется неправильным" в решении?

Мое единственное предложение было бы, чтобы вы не просто запускали потоки волей-неволей. у вас должен быть какой-то общий ExecutorService, управляющий этими потоками процесса ETL. это даст вам представление о том, что было запущено и все еще работает, а также возможность ограничивать / контролировать количество фоновых процессов (и потенциально иметь дело с любыми мошенническими выполнениями).

Вы также можете сгенерировать какой-то "jobId" для запущенного процесса и вернуть его вызывающей стороне. Затем вы можете добавить вызов к вашему API, который клиент может использовать для проверки статуса задания.

Answer 2

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

Затем запланируйте простое планирование.задача (Quartz), запущенная на cron для выбора новых задач и их выполнения.

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

В любом случае ваша текущая настройка работает, и вы на правильном пути.

Answer 3

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

Звучит так, будто вы хотите вернуть сообщение об успехе / неудаче сразу после проверки, а затем снова, если оно содержит ответ об успешном запросе.

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

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

Запуск другого потока для транзакции в порядке, если ваша нагрузка мала. Если он станет слишком высоким, ваши запросы начнут истекать, когда вы больше не сможете запускать темы