Алгоритм асинхронного запроса-ответа с ограничением времени ответа - PullRequest
0 голосов
/ 22 октября 2010

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 07 декабря 2010

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

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

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

...