Асинхронный алгоритм запроса-ответа с пределом времени ответа

Question

Я пишу обработчик сообщений для приложения передачи сообщений ebXML. Сообщение следует за шаблоном запроса-ответа. Процесс прост: отправитель отправляет сообщение, получатель получает сообщение и отправляет ответ. Все идет нормально.

При получении сообщения Получатель имеет сообщение «Время ответа» (TTR) на сообщение. Это может быть от нескольких секунд до часов/дней.

Мой вопрос заключается в следующем: как должен Отправитель иметь дело с TTR? Мне нужно, чтобы это было асинхронным процессом, поскольку TTR может быть довольно длинным (несколько дней). Как я могу как-то отсчитать таймер, но не связывать системные ресурсы в течение больших периодов времени. Могут быть большие объемы сообщений.

Моя первоначальная идея состоит в том, чтобы иметь коллекцию «Ожидание», к которой добавляется идентификатор сообщения, а также время истечения TTR. Затем я бы регулярно проводил опрос коллекции. Когда таймер истечет, Идентификатор сообщения будет перемещен в «Истекшую» коллекцию, и транзакция сообщения будет прекращена.

Когда отправитель получает ответ, он может проверить коллекцию «Ожидание» для своего сопоставленного отправленного сообщения и подтвердить, что ответ был получен вовремя. Затем сообщение будет удалено из коллекции для следующего этапа обработки.

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

Спасибо за ваш вклад

Answer 1

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

Я не понимаю цели TTR. Является ли это скорее мерой клиентской стороны, чтобы означать, что если ответ не может быть возвращен в течение определенного времени, то просто не надо его отправлять? Или он будет использоваться на сервере для планирования работы и выполнения того, что требуется сейчас, и для повторного запроса запросов с более поздним временем отклика?

Это широкий вопрос ...