Tibco RV: время жизни сообщения + отсутствие копирования для ответвлений

1. Как долго сообщение находится в очереди прослушивателя? Пока диспетчер не прочитает сообщение из очереди в сценарии «1 издатель 1 потребитель»?

Listener listener = new Listener(Queue.Default, transport, subject, new object());
listener.MessageReceived += OnMessageReceived;
Dispatcher dispatcher = new Dispatcher(listener.Queue);

2, Tibco RV обычно используется в большой разветвленной системе с относительно слабыми требованиями к надежности доставки, например, рыночные данные публикуются для 20 приложений на предприятии. Я слышал, что Tibco RV реализует решение «без копирования» для ответвлений — как это вообще возможно? Я предполагаю, что нам нужно, по крайней мере, просмотреть всех зарегистрированных слушателей для этой очереди и уведомить каждого из них, в процессе чего сообщение копируется 20 раз. Пожалуйста, просветите меня.

3. Объедините вопросы 1 и 2. Сообщение не имеет смысла находиться в очереди слушателей до тех пор, пока ВСЕ зарегистрированные слушатели не обработают сообщение. Что произойдет, если 1 из 20 приложений отключится? Это приведет к остановке процесса демона rv из-за постоянно растущего количества сообщений. Есть ли у Tibco RV ограничение на время жизни (ttl) для каждого сообщения? Как его проверить и установить новые значения?

В Google не так много соответствующей информации, поэтому, пожалуйста, помогите.

Спасибо.


listener message-queue ttl tibco-rv
person h9uest    schedule 04.03.2015    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Отличные вопросы.

  1. Имейте в виду, что если вы не используете обмен сообщениями, сертифицированный RV, сохранение на диск невозможно. Отправленные сообщения остаются в памяти отправляющего демона Rendezvous до тех пор, пока они не будут доставлены всем потребителям.

    Тем не менее, следует понимать, что RV — это оптимистичный протокол, в отличие, скажем, от TCP, который является пессимистичным протоколом. Каждый пакет, отправленный с использованием TCP, должен быть подтвержден. Этот двусторонний протокол замедляет работу. С другой стороны, Rendezvous использует протокол, который находится поверх UDP, который не требует сеансов и не требует подтверждений. Таким образом, когда демон Rendezvous отправляет сообщение, предполагается, что оно было успешно доставлено, если не получен запрос на повторную передачу. Итак, чтобы полностью ответить на ваш первый вопрос, поведение демона Rendezvous по умолчанию заключается в том, чтобы хранить отправленные им сообщения в памяти в течение 60 секунд после отправки сообщения. Это позволяет ему выполнять запросы на повторную передачу.

  2. Разветвление достигается с помощью широковещательных или многоадресных протоколов поверх UDP. Использование широковещательной передачи не рекомендуется, а рекомендуется многоадресная передача. Использование многоадресных групп требует значительно меньше сетевых ресурсов. На уровне сетевого интерфейса только те хосты, которые присоединились к группе многоадресной рассылки, будут получать пакеты, связанные с трафиком Rendezvous. Точно так же многоадресная рассылка на уровне сетевого коммутатора требует меньше ресурсов.

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

  3. В pub-sub потребители обычно получают сообщения, которые отправляются пока они живы и потребляют. Таким образом, с чистым Rendezvous, если потребитель выйдет из строя, подписка для этого потребителя будет отменена. Если мы подумаем о вашем примере с рыночными данными, это именно то поведение, которое нам нужно. IBM торгует тысячи раз в секунду, так что если я пропущу котировку, ничего страшного. Я возьму следующий. Кроме того, я не хочу просроченных цен.

    Тем не менее, иногда потребители хотят, чтобы сообщения отправлялись, когда они не работали. Этого можно добиться с помощью сертифицированного обмена сообщениями и настройки постоянных корреспондентов. Подробнее об этом см. в Руководство по концепциям рандеву. Наконец, 60-секундное поведение, о котором я упоминал в пункте №1, можно изменить с помощью параметра -reliability при запуске демона Rendezvous. В некоторых случаях это может иметь смысл (хотя для большинства распространенных случаев лучше всего использовать значение по умолчанию). Для получения более подробной информации об этом см. #context=tib_rv_administration&file=rv_adm.6.020.htm" rel="nofollow noreferrer">Руководство администратора Rendezvous.

person nochum    schedule 04.03.2015
comment
Блестящий ответ, ты мужчина! Я кое-что прочитал о многоадресной рассылке udp, и, как вы сказали, сетевые узлы, копирующие сообщения, являются ключевым моментом! Кроме того, спасибо за RV Guide за 60 секунд по умолчанию — именно то, что я искал. - person h9uest; 04.03.2015