ActiveMQ NMS: использование transport.requesttimeout с отказоустойчивым транспортом

Чтобы попытаться смягчить любые зависания, которые могут возникнуть во время проблем с подключением ActiveMQ в моем приложении, я рассматриваю возможность добавления следующего параметра в строку подключения моего брокера в моем приложении:

?transport.requesttimeout=10000

Согласно этому ресурсу, похоже, что это поможет справиться с эти инциденты.

Однако я не могу заставить это работать с моей текущей строкой подключения при отказе, которая выглядит так:

failover:(tcp://masterbroker:61616,tcp://slavebroker:61616)?keepAlive=true

Добавляя его таким образом:

failover:(tcp://masterbroker:61616,tcp://slavebroker:61616)?keepAlive=true&transport.requesttimeout=10000

Или, как вариант, вот так:

failover:(tcp://masterbroker:61616?transport.requesttimeout=10000,tcp://slavebroker:61616?transport.requesttimeout=10000)?keepAlive=true

... кажется, что оба вызывают исключения NMS или сбои при подключении.

Это может показаться относительно тривиальным вопросом, но как указать специфичные для транспорта директивы в строке подключения такого типа?


.net c# activemq nms
person rvxnet    schedule 10.04.2011    source источник
comment
Пожалуйста, посмотрите на stackoverflow.com/a/10893701/823040. Для режима отработки отказа вам потребуются transport.startupMaxReconnectAttempts, transport.timeout или подобные параметры. Полный список параметров: activemq.apache.org/nms/activemq-uri-configuration. .html. Transport.requesttimeout не является допустимой директивой для протокола отработки отказа.   -  person sgnsajgon    schedule 22.08.2014

Ответы (2)


arrow_upward
1
arrow_downward

Вы всегда должны указывать, какую версию NMS.ActiveMQ вы используете, когда задаете эти вопросы, поскольку поведение между версиями может различаться. Предполагая, что вы используете последнюю версию, я ожидаю NMSException от первой формы, если вы попытались подключиться к брокеру, и он не работал примерно через 10 секунд, это то, что URI говорит ему делать, второй URI недействителен, так как единственные параметры, которые применимы к внутренним URI конфигурации отработки отказа, относятся к вызываемому типу транспорта, в данном случае TCP.

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

Кроме того, параметр keepAlive здесь не повлияет, поскольку он не применяется к транспорту tcp, поэтому он просто будет проигнорирован. Помимо того, что поддержка активности сокета tcp практически бесполезна, поскольку она срабатывает только раз в два часа или около того, транспорты tcp будут делать для вас свои собственные сообщения, если вы не отключите монитор бездействия, поэтому им не нужно keepAlive = true.

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

-Тим www.fusesource.com

person Tim Bish    schedule 10.04.2011
comment
Спасибо за ваш ответ Тим. - person rvxnet; 11.04.2011
comment
Я использую последнюю версию NMS - v1.5.0. По сути, проблемы, которые я пытаюсь решить, - это сбои в брокере, вызывающие проблемы в моих приложениях (которые используют синхронные отправки). - person rvxnet; 11.04.2011
comment
По-прежнему неясно, что тайм-аут запроса должен исправить для вас, просто используя отказоустойчивый транспорт, вы обнаружите разорванные соединения и повторно подключитесь к новому брокеру для вас. Вы также можете настроить лимиты попыток повторного подключения и значения задержки для аварийного транспорта, если вы не хотите, чтобы клиент зависал в методе connection.Start(), если не запущен ни один брокер. - person Tim Bish; 11.04.2011

arrow_upward
-1
arrow_downward

Вместо transport.requesttimeout=10000 используйте connection.RequestTimeout=10000

person yavlad    schedule 29.10.2018
comment
Можете ли вы объяснить, почему использование connection помогло решить проблему? Дайте небольшое объяснение, почему ОП должен принять ваше решение. - person olajide; 29.10.2018