Как повторная попытка подключения AMQP работает с отработкой отказа?

Я не смог найти четкую документацию о том, как переподключение клиента JMS работает с логикой отработки отказа. Я проконсультировался со следующими официальными документами, которые соответствуют версиям, которые я использую:

Клиент JMS указывает следующий URI для аварийного переключения и повторной попытки:

String uri = new String("failover:(amqp://host1:5672,amqp://host2:5672)?&failover.maxReconnectAttempts=20");
javax.jms.ConnectionFactory connectionFactory = new org.apache.qpid.jms.JmsConnectionFactory(uri);

  • Применяется ли failover.maxReconnectAttempts к каждому URI аварийного переключения (т. е. будет повторяться 20 раз для первого URI, и если ему не удастся повторно подключиться, будет предпринята еще 20 попыток для второго URI; для меня предостережение здесь заключается в том, что с максимальное значение повторного подключения по умолчанию, равное -1, клиент будет бесконечно повторять попытки для первого URI, и, следовательно, логика отработки отказа никогда не достигнет второго URI), или это циклический перебор для обоих URI (т. е. повторяет попытку для первого URI один раз , затем второй URI также один раз, затем обратно к первому и т. д., всего 20 попыток)? Я буду тестировать это, конечно, однако, объясняется ли это поведение в официальном стандарте?

  • Учитывая, что клиент занят отправкой или получением сообщения и возникла проблема с соединением с брокером на хосте 1, будет ли также повторена операция отправки или получения? Я ожидаю, что базовое соединение будет повторено, однако не уверен, что произойдет с операцией отправки или получения. Если отправка/получение не повторяется автоматически, это означает, что на уровне отправки/получения должна быть другая логика повтора (что я считаю очень маловероятным). Как и прежде, задокументировано ли это в официальном стандарте?


java amqp jms messaging qpid
person Infinity    schedule 18.07.2018    source источник
comment
После просмотра реализация qpid proton C++, механизм повторной отработки отказа является циклическим для заданных URI, каждый полный цикл увеличивает количество повторных попыток на 1   -  person Infinity    schedule 19.07.2018

Ответы (1)


arrow_upward
3
arrow_downward

Не существует определенной спецификации поведения для того, как клиент AMQP управляет аварийным переключением, поэтому оно будет варьироваться от одной реализации к другой. Для устаревшей версии Qpid JMS, которую вы используете, клиент, я думаю (уже не могу вспомнить), считает каждую попытку подключения к удаленному URI отдельной попыткой и, следовательно, может пропустить URI, если вы настроили меньше попыток, чем URI для подключения к .

Логика повторных попыток аварийного переключения была переработана в версии 0.26.0 и теперь стала намного более надежной и предсказуемой, поэтому вам действительно следует перейти на последнюю версию, которая скоро станет 0.35.0.

То, как работает обработка отправки и получения, зависит от того, на каком этапе процесса соединение было прервано. Большую часть времени отправка будет повторяться, но есть несколько небольших промежутков времени, в течение которых вы можете получить исключение, указывающее, что отправка не удалась. Для получателя все сложнее, потому что удаленный должен решить, что произойдет с неустановленной доставкой, когда соединение обрывается, и он имеет право отправить это сообщение куда-нибудь еще.

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

person Tim Bish    schedule 20.07.2018