Ожидание HTTP-запроса в середине основного потока

Question

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

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

Надеюсь, вы поняли, что я хочу с этим требованием.

Answer 1

Мой ответ основан на некоторых предположениях. (Я не ждал, что вы ответите на мой комментарий, так как обнаружил, что проблема в любом случае имеет некоторые другие интересные функции.)

нижестоящий партнер отправит HTTP-запрос обратно в нашу систему

Для этого необходим порт прослушивания (ie, сервер), работающий на этой стороне. Этот сервер может быть в той же JVM или другой. Но ...

Этот ответ необходим для того же потока

Это немного сбивает с толку, поскольку на высоком уровне повторное использование потока программно само по себе обычно не является нашим интерес, но повторное использование объекта (независимо от того, в каком потоке). Для повторного использования потоков вы можете рассмотреть возможность использования ExecutorService. Итак, что вы можете попытаться сделать, я попытался изобразить на этой диаграмме.

Вот шаги:

1. «Потребитель элемента очереди» потребляет элемент из очереди и отправляет запрос в нисходящую систему.
2. Этот экземпляр «Потребителя элемента очереди» кэшируется для обработки запроса из нисходящей системы.
3. Есть прослушиватель, работающий на некотором порте в той же JVM, на которую нисходящая система отправляет свой запрос.
4. Прослушиватель направляет этот запрос «правильному» кэшированному экземпляру «Потребитель элемента очереди» ( Вы должны найти способ для этого на основе вашего механизма кэширования). Может быть, какой-то заголовок должен присутствовать в запросе от нисходящей системы, чтобы определить правильный обработчик на этой стороне.

Надеюсь, это работает для вас.