Hi Maryan,
On 5.2.2014 08:32, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
Hello
I'd like to note that fixing hostname requires additional development
(as a separate module/script/program) or support (by system
administrator, support staff, etc.).
I've gone the length of misconfiguring my system to either use a
hostname that can't be resolved against /etc/hosts or is resolved to a
bogus IP. I can tell you that my system (Ubuntu) complains a lot -
actually when I restarted networking after I used the unresolvable host
name my X server just died on me.
This, IMO, contradicts the saying that it is ok to have corrupted
hostname related entries. It is not. Other services tend to complain a
lot and then fall back to the loopback addres - 127.0.0.1.
As for JMX - using a hostname which is resolved to a foreign IP will
make it possible to start the management agent (there is no way to tell
that an IP is 'mine' short of looping over all the listed network
interfaces and checking their assigned IPs) but it is as far as you get.
Once you try to create a JMX connection to that application you will see
it fail - the RMI stub will use the incorrect IP and it will not be
possible for the server and the client to talk to each other.
Making the suggested (from my side) fix of JMXServiceURL.java file
should resolve current issue is the
fastest/easiest/most_clear/most_correct way (indeed IMHO).
I don't think so. You can as easily mess up the /etc/hosts not to list
"localhost" either. Even though "localhost" gets resolved to the
loopback interface IP on a particular version of a particular OS I am
not convinced that it is a required behavior (if you can provide some
resources stating otherwise I'm ready to change my position).
When the system is properly configured you should get virtually the same
result for calling getLocalHost() and getByName("localhost").
I am ready to prepare the needed patch and tests (for 7, 8, 9 versions
of jdk).
Could you please let me know if you are ready to accept following this
way (replace getLocalHost by getByName) or are you not interested in
such approach and everyone have to fix hostname?
The only quick solution for this, IMO, would be to honor
"com.sun.management.jmxremote.host" property to start agent on a
specified IP. In general, the JMX code should be reevaluated and made
more resilient to these kinds of misconfiguration. But relying on the
implementation specific behaviour ("localhost" properly resolved even
without an entry in /etc/hosts) is just not the way to go.
I have some more comments, please see further down inlined.
Thanks
P.S. Or should I send the patch and you'll make a decision after
reviewing it?
On 02/04/2014 09:20 PM, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
Hello.
Do I understand correctly that my conclusions regarding "fixing the
hostname is not an option" are incorrect?
Or may/should it be fixed in the following way:
try {
- local = InetAddress.getLocalHost();
+ local = InetAddress.getByName("localhost");
} catch (UnknownHostException e) {
Sincerely, Maryan
P.S. Sorry if my previous message was impolite or jokes were too plain
On 01/28/2014 02:50 AM, Rob McKenna wrote:
Hi Maryan,
I'm cc'ing the jmx-dev folks. (and bcc'ing the jdk7u-dev alias)
Hopefully they'll help move this conversation forward.
-Rob
On 27/01/14 20:42, Maryan Bagnyuk (aka Maryan Bahnyuk) wrote:
Hello
As a reporter of JI-9009639 / JDK-8031753
<https://bugs.openjdk.java.net/browse/JDK-8031753> bug I'd like to
inform you about the following.
Jaroslav Bachorík
<https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
a comment -2014-01-22 04:32
Not a regression.
Oops. Sorry. Indeed I should have left this field blank.
I'd understood the meaning of 'Regression' field incorrectly and had
filled it in bug report by mistake. :(
Jaroslav Bachorík
<https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
a comment -2014-01-22 04:32
If you insist on this issue being a regression, please, provide the
exact version where the behavior was as expected.
As I see all branches have this code for ages...
[marbug@server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
./src/share/classes/javax/management/remote/JMXServiceURL.java |
grep 'local = InetAddress.getLocalHost();'
/home/marbug/cpp/jab/tmp/jdk6/jdk
ohair 9 2d585507a41b Fri Jan 30 16:27:33 2009 -0800
src/share/classes/javax/management/remote/JMXServiceURL.java: local
= InetAddress.getLocalHost();
[marbug@server1 jdk]$ pwd && hg annotate -r 0 -f -a -u -d -n -c
./src/share/classes/javax/management/remote/JMXServiceURL.java |
grep 'local = InetAddress.getLocalHost();'
/home/marbug/cpp/jab/tmp/jdk6/jdk
duke 0 0c738a3e5791 Fri Jan 30 16:00:53 2009 -0800
src/share/classes/javax/management/remote/JMXServiceURL.java: local
= InetAddress.getLocalHost();
[marbug@server1 jdk]$ cd ../../jdk7u/jdk/
[marbug@server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
./src/share/classes/javax/management/remote/JMXServiceURL.java |
grep 'local = InetAddress.getLocalHost();'
/home/marbug/cpp/jab/tmp/jdk7u/jdk
duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
src/share/classes/javax/management/remote/JMXServiceURL.java: local
= InetAddress.getLocalHost();
[marbug@server1 jdk]$ cd ../../jdk8/jdk/
[marbug@server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
./src/share/classes/javax/management/remote/JMXServiceURL.java |
grep 'local = InetAddress.getLocalHost();'
/home/marbug/cpp/jab/tmp/jdk8/jdk
duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
src/share/classes/javax/management/remote/JMXServiceURL.java: local
= InetAddress.getLocalHost();
[marbug@server1 jdk]$ cd ../../jdk9/jdk/
[marbug@server1 jdk]$ pwd && hg annotate -f -a -u -d -n -c
./src/share/classes/javax/management/remote/JMXServiceURL.java |
grep 'local = InetAddress.getLocalHost();'
/home/marbug/cpp/jab/tmp/jdk9/jdk
duke 0 37a05a11f281 Sat Dec 01 00:00:00 2007 +0000
src/share/classes/javax/management/remote/JMXServiceURL.java: local
= InetAddress.getLocalHost();
So the expected behaviour is just my conslusion/suggestion.
Jaroslav Bachorík
<https://bugs.openjdk.java.net/secure/ViewProfile.jspa?name=jbachorik>added
a comment -2014-01-22 04:32
I would argue that workaround should be L - it is easy to fix the
hostname and the solution is persistent. If the reporter can
describe a situation where fixing the hostname is not an option the
workaround should stay at M.
As I understand you suggest to fix hostname and/or an appropriate
record in /etc/hosts (under Linux).
Everyone suggest this in 'google search'... :( But IMHO it's not an
option because:
1) As far as I know no one must have root access to run programs
with JMX agent.
1.1) With this suggestion everyone must have root access (because
only root or sudo-ed user may change hostname and/or /etc/hosts)
1.1.1) What if someone do not have root access to his PC (some
companies do not allow to install additional software without their
permissions)?
1.1.2) Will you add the appropriate note to the 'Install' section in
Java manual/documentation? Or should everyone just google this
exception to find the fix of this issue? :)
I would say that configuring /etc/hostname and /etc/hosts consistently
should be required. Not everybody needs to have root access - the
sysadmin should take care of it once and for all. This is all just
working around an improperly configured system.
2) Indeed Agent does not use hostname or it's IP to run JMX server
(please take a look at my original post)
2.1) If Agent does not use it (i.e. hostname/IP) then why should it
depend on it?
Because it gets imprinted into the RMI stubs used. The agents will use
this address to connect back to the agent once the RMI connection is
established. This is how RMI works.
3) Why should I change hostname if other services work correctly
without it?
3.1) OS ignores that hostname can't be resolved to some IP and is
started successfully
3.2) Apache does so too (because it listens on 0.0.0.0 in IPv4)
3.3) SSH server as well ...
3.4) etc., etc., etc.
3.5) but java throws an exception
IMHO this does not follow the 'general' scheme ;)
No, they don't. As I mentioned earlier, they usually complain a lot
(X.org, Pulse ...) or plainly die. At the end (eg. after a restart) they
decide they would fall back to loopback instead. I wouldn't call this a
'general' scheme.
4) How about JMX client (i.e. "Connecting to the JMX Agent
Programmatically ")?
http://docs.oracle.com/javase/7/docs/technotes/guides/management/agent.html#gdevg
STR:
4.1) server1 is behind NAT (example 1: on my VM, example 2: in
Amazon Cloud)
4.2) port mapping is configured from external IP to the local one
(i.e. there is only local network IP on interface)
4.3) I have associated my hostname (for instance,
server1.customer22.example.com) with 127.0.0.1 ( Is it a good idea
to do this in Amazon Cloud? IMHO no. ;) )
4.4) I start a program (Cassandra, Program4STR, etc.) via Agent
4.5) if someone will change a record for
server1.customer22.example.com to the correct external IP then why
should agent connect to external IP instead of local one? :)
4.5.1) if I run client on server1 then it's enough to connect to
localhost instead of external IP. Isn't it?
4.5.2) if I start client on another PC then in any case I'll pass
the needed value in 'host' parameter to JMXServiceURL(...)
... and when the host you use on the client doesn't match with the host
used on the server you won't be able to connect. RMI again.
5) etc., etc., etc. (see examples from my original post and imagine
how client will connect to JMX server in each case)
Indeed the decision is 'up to you' but IMHO making the suggested
change will simplify everything, save time of many people (they will
not need to change hostname and/or /etc/hosts), google will
deprecate search of ' Error: Exception thrown by the agent :
java.net.MalformedURLException: Local host name unknown:' string and
at least several developers and system administrators will be happy
not to take care about hostname ... At least for Java and programs
which use Agent ;)
Thanks
-JB-
