Завершение

Чем ack, drop, retry и retry_after становятся в ZeroMQ, где завершать нечего: ack отвечает Unsupported, а повтор - это копия, которую публикует сервис.

Схема текстом

1. Обработчик: ack(); retry(); retry_after(d); drop()
2. Доставка: AckError:: Unsupported; AckError:: Unsupported; копия через d; AckError:: Unsupported
3. Сообщение: готово: завершать нечего; пропадает, если предел не объявлен, иначе копия; копия - новое сообщение, попытка учтена; пропадает
4. ack() → AckError:: Unsupported
5. AckError:: Unsupported → готово: завершать нечего
6. retry() → AckError:: Unsupported
7. AckError:: Unsupported → пропадает, если предел не объявлен, иначе копия
8. retry_after(d) → копия через d
9. копия через d → копия - новое сообщение, попытка учтена
10. drop() → AckError:: Unsupported
11. AckError:: Unsupported → пропадает
12. Доставка не более одного раза: сообщение, которое обработчик не закончил, повторно не доставляется

Сокет ZeroMQ передаёт сообщение и забывает о нём. В протоколе нет подтверждения, поэтому ack и nack у ZmqMessage сразу отвечают AckError::Unsupported. Рантайм записывает этот ответ в журнал как предупреждение, а сообщение в любом случае считается обработанным.

Обычный retry() ничего не доставляет повторно, и обработчик второй раз не вызывается. Регистрация, которая объявляет max_attempts или адрес dead-letter, превращает retry() в копию, как для retry_after.

ZeroMQ не считает доставки, поэтому redelivery_count пуст, и попытки считает сам рантайм. Счётчик передаётся в заголовке копии x-ruststream-retry-count, и первая доставка считается первой попыткой.

Повторы

Схема текстом

1. Доставка x-ruststream-retry-count говорит, какая это попытка → Обработчик возвращает retry_after(delay) или retry() при объявленном пределе: обработана
2. Обработчик возвращает retry_after(delay) или retry() при объявленном пределе → max_attempts: попытка ниже предела?: повтор
3. max_attempts: попытка ниже предела? → Привязана: копия своему слушателю: ниже
4. max_attempts: попытка ниже предела? → Подключена или отвечает: копия по заданному адресу
5. max_attempts: попытка ниже предела? → На пределе: копия по имени dead-letter: на пределе
6. max_attempts: попытка ниже предела? → На пределе, без dead-letter: отброшена
7. Привязана: копия своему слушателю → Копия - новое сообщение, ещё одна попытка
8. Подключена или отвечает: копия по заданному адресу → Копия - новое сообщение, ещё одна попытка
9. Копия ждёт задержку внутри процесса: падение до срабатывания таймера её теряет

Исход retry_after выжидает задержку внутри процесса, а затем публикует копию через издателя повторов регистрации. Куда уходит копия, зависит от паттерна и от стороны конечной точки, и это выражено в типе.

Подписка ZmqQueue или ZmqFanout, которая привязывает свою конечную точку, сообщает своё имя в качестве адреса. Издатель повторов подключается к собственному слушателю подписки, и копия приходит туда как следующая попытка. Точка монтирования ничего не называет.

Подписка, которая подключается, читает от узла, который только отправляет. Имя отвечающей стороны ZmqRpc - не адрес: её издатель отправляет только по идентичностям из запросов. Ни у той, ни у другой нет адреса для копии, поэтому точка монтирования называет, куда уходят копии, - обычно это очередь, которую сервис привязывает для себя. Цепочка роутера без адреса не компилируется, а регистрацию без адреса отвергает старт.

На пределе доставка уходит по адресу dead-letter через того же издателя, поэтому этот адрес принадлежит издателю на другой конечной точке. На конечной точке, которую привязывает подписка на очередь, dead-letter вернулась бы к той же подписке: издатель её не отправляет, и доставка отбрасывается. На привязанной широковещательной конечной точке имя dead-letter под префиксом подписки приходит обратно к ней. Без адреса dead-letter доставка отбрасывается с предупреждением.