Параметры ActiveMQ InactivityMonitor не применяются к транспортному соединению HTTP - PullRequest
Новая
       12

Параметры ActiveMQ InactivityMonitor не применяются к транспортному соединению HTTP

1 голос
/ 18 марта 2020

В моей команде мы используем ActiveMQ 5.15.11 в производстве, и наши потребители сообщений подключаются по протоколу HTTP. Поскольку у нас есть проблемы с сетью на стороне потребителя, мы попытались отключить InactivityMonitor в activemq. xml (см. Ниже) 

    <transportConnectors>
        <transportConnector name="openwire" uri="tcp://host:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"/>
        <transportConnector name="http" uri="http://host:61617?wireFormat.maxInactivityDuration=0"/>
    </transportConnectors>

Похоже, что " wireFormat.maxInactivityDuration = 0"не применяется, так как у нас есть журналы от InactivityMonitor для потребителя: 

2020-03-18 00:00:03,426 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,426 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]
2020-03-18 00:00:03,509 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,509 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]
2020-03-18 00:00:03,514 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,514 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]
2020-03-18 00:00:03,642 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,642 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]
2020-03-18 00:00:03,706 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,706 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]
2020-03-18 00:00:03,738 [DEBUG] -  -  - WriteChecker: 10000ms elapsed since last write check.
2020-03-18 00:00:03,738 [DEBUG] -  -  - Running WriteCheck[https://host:443/activemq]

Кроме того, как только мы получаем длинную сетевую задержку, мы также получаем log: 

2020-03-01 20:43:17,578 [WARN ] -  -  - Transport (https://host:443/activemq) failed , attempting to automatically reconnect: {}
org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: https://host:443/activemq
    at org.apache.activemq.transport.AbstractInactivityMonitor$5.run(AbstractInactivityMonitor.java:246)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

Примечание 1: клиенты ActiveMQ Потребители JMS .

Примечание 2: мы попытались отключить InactivityMonitor для транспорта TCP и это хорошо работает с этим протоколом.

Спасибо за вашу помощь заранее.

1 Ответ

1 голос
/ 18 марта 2020

Для транспорта HTTP я не думаю, что стандартный шаг согласования протокола OpenWire выполнен, что, вероятно, означает, что конфигурация на стороне сервера max-inactivity-duration видна на стороне клиента. Это приводит к тому, что клиент использует значения по умолчанию для проверок бездействия, которые, как я помню, составляют примерно 30 секунд, а затем разделяются на меньшие порции для проверок чтения и записи.

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

На стороне клиента вы сможете отключить монитор неактивности с помощью transport.useInactivityMonitor=false или, возможно, просто useInactivityMonitor=false на URI.

...