похоже, что ваша финальная цитата приходит слишком рано. Он должен быть после последнего параметра.
У меня этот трюк сработал.
Я заметил кое-что интересное: когда я запускаю свое приложение, используя следующую командную строку:
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, только с реальных физических удаленных хостов. Итак, я предполагаю, что эта проверка выполняется только тогда, когда соединение идет "извне".