Как я фиксирую 'Неудавшийся для получения тупиковой' ошибки JMX RMIServer?
Я переместил бы VPN в брандмауэр (любая основная Cisco может обработать это очень хорошо),
Установите две зоны, Вашу "Безопасную зону", которая содержит Вашу базу данных и серверы бэкэнда, что-либо, что хранит частную или уязвимую информацию.
Затем Ваша демилитаризованная зона для Вашего веб-сервера (веб-серверов). Если Ваш веб-сервер когда-нибудь взламывается (его больше вопроса когда, то, если.) У них нет прямого доступа к машинам с уязвимой информацией.
Править: Это предполагает, что у Вас есть брандмауэр, способный к выполнению VPN. (Вы ничего не упоминали о брандмауэре. Если Вы не делаете, я поместил VPN на веб-сервер. Не наилучший вариант, но могло быть хуже. Я также предлагаю некоторый вход / программное обеспечение растяжки для Ваших веб-серверов в случае, они действительно становятся скомпрометированными, Вы будете знать об этом как можно быстрее. Надо надеяться, можно завершить работу их, прежде чем они получат Ключи VPN, начните ковать базы данных или начните вызывать большие проблемы :P.
Проблема в том, что даже если JMX настроен на прослушивание порта 8084, после того, как начальное соединение установлено, хост JMX будет динамически выбирать другой порт для остальной части «разговора». Мой брандмауэр разрешал трафик через 8084, но блокировал последующий трафик.
Есть два варианта.
- Разрешить входящий трафик на всех эфемерных портах (ура!).
- Разработать оболочку JMX, которая использует единственный порт для связь.
Вы можете указать тот же порт для диалога JMX и RMI:
-Dcom.sun.management.jmxremote.port=8084
-Dcom.sun.management.jmxremote.rmi.port=8084
Я боролся с этой же проблемой, пытаясь подключиться к нашим новым виртуальным машинам Tomcat8 через JMX (используя VisualVM). Нашей команде Linux пришлось открыть заявку на Redhat, чтобы помочь нам в устранении неполадок. Но я наткнулся на эту статью, прежде чем они смогли решить нашу проблему.
Решение, упомянутое выше, заключалось в том, чтобы добавить
-Dcom.sun.management.jmxremote.rmi.port=X
и X , которые должны соответствовать вашим настройкам для
-Dcom.sun.management.jmxremote.port
Полный список аргументов:
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8091
-Dcom.sun.management.jmxremote.rmi.port=8091
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=MYHOST
Надеюсь, это поможет кому-то еще, у кого есть такая же проблема. Удачи!
У меня такая же проблема на tomcat 9.0.9.
на пути / к / tomcat / bin / setenv.sh у меня работала следующая конфигурация:
CATALINA_OPTS="$CATALINA_OPTS
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=192.168.1.20
-Djmx.rmi.registry.port=1099
-Djmx.rmi.port=1099
"
export CATALINA_OPTS
В поисках решения идентичной проблемы (после решения многих многих других, готов дергать себя за волосы), я нашел эту тему, и я могу поделиться, что решение, которое сработало для меня, былоhttps://serverfault.com/a/872756/579378от @MaxRelax --Я бы проголосовал за его ответ, но у меня недостаточно репутации.
Да, еще кое-что.:Поскольку -Dcom.sun.management.jmxremote.ssl=falseне забудьте установить флажок «Не требовать подключения SSL» в диалоговом окне Java Visual VM для добавления соединения JMX.