Я пытаюсь открыть соединение JMX с java-приложением, запущенным на удаленной машине.
Приложение JVM настроено со следующими параметрами:
- com.sun.management.jmxremote
- com.sun.management.jmxremote.port = 1088
- com.sun.management.jmxremote.authenticate = ложь
- com.sun.management.jmxremote.ssl = ложь
Я могу подключиться с помощью localhost:1088
с помощью jconsole или jvisualvm.
Но я не могу подключиться с помощью xxx.xxx.xxx.xxx:1088
с удаленной машины.
Между серверами или ОС нет брандмауэра. Но для устранения этой возможности я telnet xxx.xxx.xxx.xxx 1088
и я думаю, что она подключается, так как экран консоли становится пустым.
Оба сервера - это Windows Server 2008 x64. Пробовал с 64-битным JVM и 32-битным, не работает.
Ответ 1
Если бы в Linux проблема заключалась в том, что localhost - это loopback-интерфейс, вам нужно приложение для привязки к вашему сетевому интерфейсу.
Вы можете использовать netstat, чтобы подтвердить, что он не связан с ожидаемым сетевым интерфейсом.
Вы можете сделать эту работу, вызвав программу системным параметром java.rmi.server.hostname="YOUR_IP"
, либо как переменную среды, либо используя
java -Djava.rmi.server.hostname=YOUR_IP YOUR_APP
Ответ 2
Я потратил больше одного дня, пытаясь заставить JMX работать извне localhost. Кажется, что SUN/Oracle не предоставили хорошую документацию по этому вопросу.
Убедитесь, что следующая команда возвращает реальный IP-адрес или HOSTNAME. Если он возвращает что-то вроде 127.0.0.1, 127.0.1.1 или localhost, это не сработает, и вам придется обновить файл /etc/hosts
.
hostname -i
Вот команда, необходимая для включения JMX даже извне
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=1100
-Djava.rmi.server.hostname=myserver.example.com
Где, как вы предполагали, myserver.example.com должен соответствовать тому, что возвращает hostname -i
.
Очевидно, что вам нужно быть уверенным, что брандмауэр не блокирует вас, но я почти уверен, что это не ваша проблема, проблема заключается в последнем параметре, который не документирован.
Ответ 3
http://blogs.oracle.com/jmxetc/entry/troubleshooting_connection_problems_in_jconsole
Если вы пытаетесь получить доступ к серверу, который находится за NAT, вам, скорее всего, придется запустить свой сервер с опцией
-Djava.rmi.server.hostname=<public/NAT address>
чтобы концы RMI, отправленные клиенту, содержали общедоступный адрес сервера, позволяющий ему получать клиенты извне.
Ответ 4
В моем тестировании с Tomcat и Java 8 JVM открывал эфемерный порт в дополнение к тому, который был указан для JMX. Следующий код исправил меня; попробуйте, если у вас возникли проблемы, когда ваш JMX-клиент (например, VisualVM не подключается.
-Dcom.sun.management.jmxremote.port=8989
-Dcom.sun.management.jmxremote.rmi.port=8989
Также см. Почему Java открывает 3 порта при настройке JMX?
Ответ 5
это означает, что ваша конечная цитата приходит слишком рано. Он должен быть после последнего параметра.
Этот трюк работал у меня.
Я заметил что-то интересное: когда я запускаю свое приложение, используя следующую командную строку:
java -Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
Если я попытаюсь подключиться к этому порту с удаленного компьютера с помощью jconsole, соединение TCP будет успешным, некоторые данные будут обмениваться между удаленным jconsole и локальным агентом jmx, где развернут мой MBean, а затем jconsole отображает сообщение об ошибке подключения. Я выполнил захват wirehark, и он показывает обмен данными, поступающий как от агента, так и от jconsole.
Таким образом, это не проблема сети, если я выполняю netstat -an с или без свойства java.rmi.server.hostname, у меня есть следующие привязки:
TCP 0.0.0.0:9999 0.0.0.0:0 LISTENING
TCP [::]:9999 [::]:0 LISTENING
Это означает, что в обоих случаях сокет, созданный на порте 9999, принимает соединения с любого хоста по любому адресу.
Я думаю, что содержимое этого системного свойства используется где-то в соединении и сравнивается с фактическим IP-адресом, используемым агентом для связи с jconsole. И если эти адреса не совпадают, соединение терпит неудачу.
У меня не было этой проблемы при подключении с одного хоста с помощью jconsole, только от реальных физических удаленных хостов. Итак, я полагаю, что эта проверка выполняется только тогда, когда соединение происходит от "снаружи".
Ответ 6
Большое спасибо, он работает следующим образом:
java -Djava.rmi.server.hostname = xxx.xxx.xxx.xxx -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.ssl = false -Dcom. sun.management.jmxremote.authenticate = false -Dcom.sun.management.jmxremote.port = 25000 -jar myjar.jar
Ответ 7
то, что работает для меня, заключалось в том, чтобы установить /etc/hosts, чтобы указать имя хоста на ip, а не на интерфейс loopback, а затем перезапустить мое приложение.
cat/etc/hosts
127.0.0.1 localhost.localdomain localhost
192.168.0.1 myservername
Это моя конфигурация:
-Dcom.sun.management.jmxremote.port=1617
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
Ответ 8
У меня такая же проблема, и я меняю любое имя хоста, совпадающее с именем локального хоста, на 0.0.0.0, похоже, работает после этого.
Ответ 9
Чтобы включить удаленный JMX, пройдите ниже параметров VM вместе с командой JAVA.
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=453
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=myDomain.in
Ответ 10
Попробуйте использовать порты более 3000.