меж-http запрос связи - PullRequest
0 голосов
/ 21 мая 2018

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

MessageEndpoints и активаторы службы могут подписаться на канал, но как это будет в том же потоке, что и второй http-вызов на второй конечной точке, я не могу понять.Для меня загадка в том, как второй поток во второй конечной точке блокируется, пока не получит сообщение, которое создает и отправляет первая конечная точка.

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

Заранее спасибо.

1 Ответ

0 голосов
/ 21 мая 2018

Похоже на задачу для шаблона Aggregator EI:

http://www.enterpriseintegrationpatterns.com/patterns/messaging/Aggregator.html

https://docs.spring.io/spring-integration/docs/5.0.5.RELEASE/reference/html/messaging-routing-chapter.html#aggregator

Оба запроса должны соответствовать одной группе.

Мне почему-то кажется, что для вас не имеет значения, кто вернется первым: единственная забота - выполнить некоторую постобработку, когда собраны все данные.

Однако я даже думаю, что Scatter-Gather также является хорошим выбором для вас:

https://docs.spring.io/spring-integration/docs/5.0.5.RELEASE/reference/html/messaging-routing-chapter.html#scatter-gather

Существует также реализация Thread Barrier: https://docs.spring.io/spring-integration/docs/5.0.5.RELEASE/reference/html/messaging-routing-chapter.html#barrier

...