From belliottsmith at datastax.com Tue Feb 4 06:54:35 2014 From: belliottsmith at datastax.com (Benedict Elliott Smith) Date: Tue, 4 Feb 2014 14:54:35 +0000 Subject: jmx-dev JMX RMIConnectionImpl Memory "Leak" Message-ID: Hi, Introduced in this webrev: http://hg.openjdk.java.net/icedtea/jdk7/jdk/rev/985b53122cf8 The CombinedClassLoader introduced here resolves any classes it loads against itself, or its ClassLoaderWrapper wrapped defaultCL, as opposed to its parent or the defaultCL directly. This appears to be deliberate, and I assume is to avoid classes remaining loaded when they are no longer needed by JMX. However the result is that every time a JMX method is invoked, or a new connection is established (or a number of other actions are taken), any classes not already loaded in the context class loader are repeatedly loaded and resolved against a different CL. The upshot of this is that the permgen gets rapidly filled with these classes. The end result of which is that the VM can OOM under very low load and very low heap utilisation, as unless you are generating enough garbage to trigger a full GC these classes will not be collected. The workaround is to introduce the CMSClassUnloadingEnabled flag, but it seems to me that the problem would be better addressed at the source, as this is fairly undesirable behaviour. It seems that, if the desire is to reduce wasted memory from classes loaded for JMX but not used by the rest of the VM, the best solution might be to map the original class loaders to a SoftReference to a shared wrapping class loader for that pair. This should retain the current behaviour of not resolving against the original class loaders whilst ensuring we don't proliferate many class loaders with the same classes. Alternatively, if the reason for these wrappers is simply to perform proxying, I would suggest that simply resolving against the original CLs would be preferable. I can't see why loading these classes against the original CLs would be so detrimental, but I may be missing something. I'd be happy to submit a patch for this if a preferred solution can be reached. Thanks, Benedict -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20140204/c21ac4ec/attachment.html From marbuga at gmail.com Tue Feb 4 11:20:47 2014 From: marbuga at gmail.com (Maryan Bagnyuk (aka Maryan Bahnyuk)) Date: Tue, 04 Feb 2014 21:20:47 +0200 Subject: jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced In-Reply-To: <52E6FECF.7030408@oracle.com> References: <52E6C4D2.3060703@gmail.com> <52E6FECF.7030408@oracle.com> Message-ID: <52F13D8F.6030806@gmail.com> 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 >> bug I'd like to >> inform you about the following. >> >> >> Jaroslav Bachor?k >> 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 >> 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 at 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 at 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 at server1 jdk]$ cd ../../jdk7u/jdk/ >> [marbug at 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 at server1 jdk]$ cd ../../jdk8/jdk/ >> [marbug at 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 at server1 jdk]$ cd ../../jdk9/jdk/ >> [marbug at 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 >> 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? :) >> >> 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? >> >> 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 ;) >> >> 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(...) >> >> 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 >> > -- Sincerely, Maryan Bagnyuk (aka Maryan Bahnyuk) marbuga at gmail.com marbug at mail.ru marbug at meta.ua Cell phone (MTS): 066-498-99-24 Cell phone (Kyivstar): 067-131-27-37 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20140204/c187b647/attachment-0001.html From marbuga at gmail.com Tue Feb 4 23:32:25 2014 From: marbuga at gmail.com (Maryan Bagnyuk (aka Maryan Bahnyuk)) Date: Wed, 05 Feb 2014 09:32:25 +0200 Subject: jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced In-Reply-To: <52F13D8F.6030806@gmail.com> References: <52E6C4D2.3060703@gmail.com> <52E6FECF.7030408@oracle.com> <52F13D8F.6030806@gmail.com> Message-ID: <52F1E909.60503@gmail.com> 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.). 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 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? 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 >>> bug I'd like to >>> inform you about the following. >>> >>> >>> Jaroslav Bachor?k >>> 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 >>> 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 at 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 at 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 at server1 jdk]$ cd ../../jdk7u/jdk/ >>> [marbug at 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 at server1 jdk]$ cd ../../jdk8/jdk/ >>> [marbug at 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 at server1 jdk]$ cd ../../jdk9/jdk/ >>> [marbug at 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 >>> 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? :) >>> >>> 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? >>> >>> 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 ;) >>> >>> 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(...) >>> >>> 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 >>> >> > -- Sincerely, Maryan Bagnyuk (aka Maryan Bahnyuk) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20140205/0d7762b0/attachment.html From jaroslav.bachorik at oracle.com Wed Feb 5 03:33:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Wed, 05 Feb 2014 12:33:34 +0100 Subject: jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced In-Reply-To: <52F1E909.60503@gmail.com> References: <52E6C4D2.3060703@gmail.com> <52E6FECF.7030408@oracle.com> <52F13D8F.6030806@gmail.com> <52F1E909.60503@gmail.com> Message-ID: <52F2218E.6070306@oracle.com> 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 >>>> bug I'd like to >>>> inform you about the following. >>>> >>>> >>>> Jaroslav Bachor?k >>>> 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 >>>> 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 at 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 at 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 at server1 jdk]$ cd ../../jdk7u/jdk/ >>>> [marbug at 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 at server1 jdk]$ cd ../../jdk8/jdk/ >>>> [marbug at 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 at server1 jdk]$ cd ../../jdk9/jdk/ >>>> [marbug at 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 >>>> 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- From marbuga at gmail.com Wed Feb 5 11:50:51 2014 From: marbuga at gmail.com (Maryan Bagnyuk (aka Maryan Bahnyuk)) Date: Wed, 05 Feb 2014 21:50:51 +0200 Subject: jmx-dev JDK-8031753: JMXServiceURL should not use getLocalHost or its usage should be enhanced In-Reply-To: <52F2218E.6070306@oracle.com> References: <52E6C4D2.3060703@gmail.com> <52E6FECF.7030408@oracle.com> <52F13D8F.6030806@gmail.com> <52F1E909.60503@gmail.com> <52F2218E.6070306@oracle.com> Message-ID: <52F2961B.4040708@gmail.com> Dear Jaroslav Thank you for the prompt answer. > 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. > Ok. Let's move this way (i.e. use "com.sun.management.jmxremote.host"). As I understand "com.sun.management.jmxremote.host" can't be a mandatory variable (otherwise agent will not start after jdk update). And backward compatibility is also preferred/expected (i.e. everything should work the same way before and after "com.sun.management.jmxremote.host" usage implementation). So am I correct assuming that the following sequence of checks/validations is correct/suitable? 1) if "com.sun.management.jmxremote.host" is defined then goto 1.1 (otherwise goto 2) 1.1) validate it's value 1.2) if value is valid then use it and 'return' (otherwise goto 2) 2) if getLocalHost() returns a value without exception then use this value and 'return' (otherwise goto 3) 3) if getByName("localhost") returns without exception then use it and 'return' (otherwise goto 4) 4) throw exception Question 1: Should step 3 be leaved as-is or deprecated? (IMHO it will make JMX more resilient but it will be more useful to ensure that you agree) Question 2: Should 127.0.0.1 or :::1 (depending on the used protocol version) be used instead of 4-th step or such kind of resilience (i.e. "exception is not thrown") will make everything more complex? Sincerely, Maryan P.S. I also use Ubuntu (indeed Ubuntu Desktop, not Ubuntu Server) on my PCs but I don't have a time/wish/need to support it. If I had had to resolve the described issues (with X.org, Pulse, etc) then I'd probably send the appropriate bug report if investigation showed that hostname had not been needed at all. P.P.S. I have had a practice of using Ubuntu Desktop as 'server OS' for a small company. But in most cases my previous/present coworkers and I use 'server OSs' without X.org, Pulse, etc. And the used services (in most cases) ignore hostname resolving. But it's a long story and a subject of a separate discussion. P.P.P.S. Thanks again for moving current discussion forward. Have a nice day. On 02/05/2014 01:33 PM, Jaroslav Bachorik wrote: > 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 >>>>> bug I'd like to >>>>> inform you about the following. >>>>> >>>>> >>>>> Jaroslav Bachor?k >>>>> 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 >>>>> 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 at 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 at 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 at server1 jdk]$ cd ../../jdk7u/jdk/ >>>>> [marbug at 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 at server1 jdk]$ cd ../../jdk8/jdk/ >>>>> [marbug at 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 at server1 jdk]$ cd ../../jdk9/jdk/ >>>>> [marbug at 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 >>>>> 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- > -- Sincerely, Maryan Bagnyuk (aka Maryan Bahnyuk) From jaroslav.bachorik at oracle.com Fri Feb 14 05:39:19 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 14:39:19 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use Message-ID: <52FE1C87.9060800@oracle.com> Please, review this test change. Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 The test is currently using a well-known SSH port 22 to make sure it is not possible to start the management agent on this port. However, this may fail when SSH server is not running on a test machine. The fix adds the possibility to to start up a dummy socket server in the tested application and use the port from that socket server to make sure that the management agent refuses to start on that port. Thanks, -JB- From daniel.fuchs at oracle.com Fri Feb 14 06:43:34 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Feb 2014 15:43:34 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE1C87.9060800@oracle.com> References: <52FE1C87.9060800@oracle.com> Message-ID: <52FE2B96.7080703@oracle.com> Hi Jaroslav, I agree with the idea, but the following logic looks suspect: 378 for(String arg : args) { 379 if (arg.startsWith("-")) { 380 pbArgs.add(0, arg); // VM arg 381 } else { 382 pbArgs.add(arg); // application arg 383 } 384 } it will inverse the orders of VM args in the sub process, and will have unpredictable results if any of those args accept parameters - such as '-cp ' which would result in being taken as an application arg. It's difficult to say whether such a situation can or can't happen, but I suspect it would be safer to simply look for the "allocate_port" string or pass the "allocate_port" as a system property (e.g -Dallocate.port=true) - which would remove the need for that loop... best regards, -- daniel On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: > Please, review this test change. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 > Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 > > The test is currently using a well-known SSH port 22 to make sure it is > not possible to start the management agent on this port. However, this > may fail when SSH server is not running on a test machine. > > The fix adds the possibility to to start up a dummy socket server in the > tested application and use the port from that socket server to make sure > that the management agent refuses to start on that port. > > Thanks, > > -JB- From daniel.fuchs at oracle.com Fri Feb 14 06:54:04 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Feb 2014 15:54:04 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE2B96.7080703@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> Message-ID: <52FE2E0C.3070801@oracle.com> BTW - it occurs to me that it doesn't really matters which process opens the ServerSocket - does it? So you might as well create the server socket before calling jcmd() - can't you? -- daniel On 2/14/14 3:43 PM, Daniel Fuchs wrote: > Hi Jaroslav, > > I agree with the idea, but the following logic looks suspect: > > 378 for(String arg : args) { > 379 if (arg.startsWith("-")) { > 380 pbArgs.add(0, arg); // VM arg > 381 } else { > 382 pbArgs.add(arg); // application arg > 383 } > 384 } > > it will inverse the orders of VM args in the sub process, and > will have unpredictable results if any of those args accept > parameters - such as '-cp ' which would result in > being taken as an application arg. > > It's difficult to say whether such a situation can or can't happen, > but I suspect it would be safer to simply look for the "allocate_port" > string or pass the "allocate_port" as a system property > (e.g -Dallocate.port=true) - which would remove the need for that > loop... > > best regards, > > -- daniel > > On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >> Please, review this test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >> >> The test is currently using a well-known SSH port 22 to make sure it is >> not possible to start the management agent on this port. However, this >> may fail when SSH server is not running on a test machine. >> >> The fix adds the possibility to to start up a dummy socket server in the >> tested application and use the port from that socket server to make sure >> that the management agent refuses to start on that port. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Fri Feb 14 06:55:27 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 15:55:27 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE2B96.7080703@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> Message-ID: <52FE2E5F.7040109@oracle.com> On 14.2.2014 15:43, Daniel Fuchs wrote: > Hi Jaroslav, > > I agree with the idea, but the following logic looks suspect: > > 378 for(String arg : args) { > 379 if (arg.startsWith("-")) { > 380 pbArgs.add(0, arg); // VM arg > 381 } else { > 382 pbArgs.add(arg); // application arg > 383 } > 384 } > > it will inverse the orders of VM args in the sub process, and > will have unpredictable results if any of those args accept > parameters - such as '-cp ' which would result in > being taken as an application arg. > > It's difficult to say whether such a situation can or can't happen, > but I suspect it would be safer to simply look for the "allocate_port" > string or pass the "allocate_port" as a system property > (e.g -Dallocate.port=true) - which would remove the need for that > loop... Aaa, system property sounds good. Thanks! -JB- > > best regards, > > -- daniel > > On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >> Please, review this test change. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >> >> The test is currently using a well-known SSH port 22 to make sure it is >> not possible to start the management agent on this port. However, this >> may fail when SSH server is not running on a test machine. >> >> The fix adds the possibility to to start up a dummy socket server in the >> tested application and use the port from that socket server to make sure >> that the management agent refuses to start on that port. >> >> Thanks, >> >> -JB- > From jaroslav.bachorik at oracle.com Fri Feb 14 06:59:23 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 15:59:23 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE2E0C.3070801@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> <52FE2E0C.3070801@oracle.com> Message-ID: <52FE2F4B.7060708@oracle.com> On 14.2.2014 15:54, Daniel Fuchs wrote: > > BTW - it occurs to me that it doesn't really matters which > process opens the ServerSocket - does it? So you might as > well create the server socket before calling jcmd() - can't > you? Yes, actually, the socket server could be created at the beginning of the test. That would resolve all the port number passing. -JB- > > -- daniel > > On 2/14/14 3:43 PM, Daniel Fuchs wrote: >> Hi Jaroslav, >> >> I agree with the idea, but the following logic looks suspect: >> >> 378 for(String arg : args) { >> 379 if (arg.startsWith("-")) { >> 380 pbArgs.add(0, arg); // VM arg >> 381 } else { >> 382 pbArgs.add(arg); // application arg >> 383 } >> 384 } >> >> it will inverse the orders of VM args in the sub process, and >> will have unpredictable results if any of those args accept >> parameters - such as '-cp ' which would result in >> being taken as an application arg. >> >> It's difficult to say whether such a situation can or can't happen, >> but I suspect it would be safer to simply look for the "allocate_port" >> string or pass the "allocate_port" as a system property >> (e.g -Dallocate.port=true) - which would remove the need for that >> loop... >> >> best regards, >> >> -- daniel >> >> On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >>> Please, review this test change. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >>> >>> The test is currently using a well-known SSH port 22 to make sure it is >>> not possible to start the management agent on this port. However, this >>> may fail when SSH server is not running on a test machine. >>> >>> The fix adds the possibility to to start up a dummy socket server in the >>> tested application and use the port from that socket server to make sure >>> that the management agent refuses to start on that port. >>> >>> Thanks, >>> >>> -JB- >> > From shanliang.jiang at oracle.com Fri Feb 14 07:02:51 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 14 Feb 2014 16:02:51 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE2F4B.7060708@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> <52FE2E0C.3070801@oracle.com> <52FE2F4B.7060708@oracle.com> Message-ID: <52FE301B.2080108@oracle.com> Jaroslav Bachorik wrote: > On 14.2.2014 15:54, Daniel Fuchs wrote: >> >> BTW - it occurs to me that it doesn't really matters which >> process opens the ServerSocket - does it? So you might as >> well create the server socket before calling jcmd() - can't >> you? > > Yes, actually, the socket server could be created at the beginning of > the test. That would resolve all the port number passing. and no need to create a thread to listen on the server socket, like JMXStartStopDoSomething.serverThread. Shanliang > > -JB- > >> >> -- daniel >> >> On 2/14/14 3:43 PM, Daniel Fuchs wrote: >>> Hi Jaroslav, >>> >>> I agree with the idea, but the following logic looks suspect: >>> >>> 378 for(String arg : args) { >>> 379 if (arg.startsWith("-")) { >>> 380 pbArgs.add(0, arg); // VM arg >>> 381 } else { >>> 382 pbArgs.add(arg); // application arg >>> 383 } >>> 384 } >>> >>> it will inverse the orders of VM args in the sub process, and >>> will have unpredictable results if any of those args accept >>> parameters - such as '-cp ' which would result in >>> being taken as an application arg. >>> >>> It's difficult to say whether such a situation can or can't happen, >>> but I suspect it would be safer to simply look for the "allocate_port" >>> string or pass the "allocate_port" as a system property >>> (e.g -Dallocate.port=true) - which would remove the need for that >>> loop... >>> >>> best regards, >>> >>> -- daniel >>> >>> On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >>>> Please, review this test change. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >>>> >>>> The test is currently using a well-known SSH port 22 to make sure >>>> it is >>>> not possible to start the management agent on this port. However, this >>>> may fail when SSH server is not running on a test machine. >>>> >>>> The fix adds the possibility to to start up a dummy socket server >>>> in the >>>> tested application and use the port from that socket server to make >>>> sure >>>> that the management agent refuses to start on that port. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Fri Feb 14 07:34:34 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 14 Feb 2014 16:34:34 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE301B.2080108@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> <52FE2E0C.3070801@oracle.com> <52FE2F4B.7060708@oracle.com> <52FE301B.2080108@oracle.com> Message-ID: <52FE378A.5050909@oracle.com> On 14.2.2014 16:02, shanliang wrote: > Jaroslav Bachorik wrote: >> On 14.2.2014 15:54, Daniel Fuchs wrote: >>> >>> BTW - it occurs to me that it doesn't really matters which >>> process opens the ServerSocket - does it? So you might as >>> well create the server socket before calling jcmd() - can't >>> you? >> >> Yes, actually, the socket server could be created at the beginning of >> the test. That would resolve all the port number passing. > and no need to create a thread to listen on the server socket, like > JMXStartStopDoSomething.serverThread. Thanks. Fix simplified - http://cr.openjdk.java.net/~jbachorik/8034177/webrev.01 -JB- > > Shanliang >> >> -JB- >> >>> >>> -- daniel >>> >>> On 2/14/14 3:43 PM, Daniel Fuchs wrote: >>>> Hi Jaroslav, >>>> >>>> I agree with the idea, but the following logic looks suspect: >>>> >>>> 378 for(String arg : args) { >>>> 379 if (arg.startsWith("-")) { >>>> 380 pbArgs.add(0, arg); // VM arg >>>> 381 } else { >>>> 382 pbArgs.add(arg); // application arg >>>> 383 } >>>> 384 } >>>> >>>> it will inverse the orders of VM args in the sub process, and >>>> will have unpredictable results if any of those args accept >>>> parameters - such as '-cp ' which would result in >>>> being taken as an application arg. >>>> >>>> It's difficult to say whether such a situation can or can't happen, >>>> but I suspect it would be safer to simply look for the "allocate_port" >>>> string or pass the "allocate_port" as a system property >>>> (e.g -Dallocate.port=true) - which would remove the need for that >>>> loop... >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >>>>> Please, review this test change. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >>>>> >>>>> The test is currently using a well-known SSH port 22 to make sure >>>>> it is >>>>> not possible to start the management agent on this port. However, this >>>>> may fail when SSH server is not running on a test machine. >>>>> >>>>> The fix adds the possibility to to start up a dummy socket server >>>>> in the >>>>> tested application and use the port from that socket server to make >>>>> sure >>>>> that the management agent refuses to start on that port. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> > From daniel.fuchs at oracle.com Fri Feb 14 07:56:18 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 14 Feb 2014 16:56:18 +0100 Subject: jmx-dev RFR 8034177: sun/management/jmxremote/startstop/JMXStartStopTest.java should report port in use In-Reply-To: <52FE378A.5050909@oracle.com> References: <52FE1C87.9060800@oracle.com> <52FE2B96.7080703@oracle.com> <52FE2E0C.3070801@oracle.com> <52FE2F4B.7060708@oracle.com> <52FE301B.2080108@oracle.com> <52FE378A.5050909@oracle.com> Message-ID: <52FE3CA2.9090705@oracle.com> On 2/14/14 4:34 PM, Jaroslav Bachorik wrote: > On 14.2.2014 16:02, shanliang wrote: >> Jaroslav Bachorik wrote: >>> On 14.2.2014 15:54, Daniel Fuchs wrote: >>>> >>>> BTW - it occurs to me that it doesn't really matters which >>>> process opens the ServerSocket - does it? So you might as >>>> well create the server socket before calling jcmd() - can't >>>> you? >>> >>> Yes, actually, the socket server could be created at the beginning of >>> the test. That would resolve all the port number passing. >> and no need to create a thread to listen on the server socket, like >> JMXStartStopDoSomething.serverThread. > Hi Jaroslav, > Thanks. Fix simplified - > http://cr.openjdk.java.net/~jbachorik/8034177/webrev.01 That's much simpler :-) You can remove the unused imports from JMXStartStopDoSomething, no need to regenerate a webrev. Consider it reviewed :-) -- daniel > > -JB- > >> >> Shanliang >>> >>> -JB- >>> >>>> >>>> -- daniel >>>> >>>> On 2/14/14 3:43 PM, Daniel Fuchs wrote: >>>>> Hi Jaroslav, >>>>> >>>>> I agree with the idea, but the following logic looks suspect: >>>>> >>>>> 378 for(String arg : args) { >>>>> 379 if (arg.startsWith("-")) { >>>>> 380 pbArgs.add(0, arg); // VM arg >>>>> 381 } else { >>>>> 382 pbArgs.add(arg); // application arg >>>>> 383 } >>>>> 384 } >>>>> >>>>> it will inverse the orders of VM args in the sub process, and >>>>> will have unpredictable results if any of those args accept >>>>> parameters - such as '-cp ' which would result in >>>>> being taken as an application arg. >>>>> >>>>> It's difficult to say whether such a situation can or can't happen, >>>>> but I suspect it would be safer to simply look for the "allocate_port" >>>>> string or pass the "allocate_port" as a system property >>>>> (e.g -Dallocate.port=true) - which would remove the need for that >>>>> loop... >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> >>>>> On 2/14/14 2:39 PM, Jaroslav Bachorik wrote: >>>>>> Please, review this test change. >>>>>> >>>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8034177 >>>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8034177/webrev.00 >>>>>> >>>>>> The test is currently using a well-known SSH port 22 to make sure >>>>>> it is >>>>>> not possible to start the management agent on this port. However, >>>>>> this >>>>>> may fail when SSH server is not running on a test machine. >>>>>> >>>>>> The fix adds the possibility to to start up a dummy socket server >>>>>> in the >>>>>> tested application and use the port from that socket server to make >>>>>> sure >>>>>> that the management agent refuses to start on that port. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -JB- >>>>> >>>> >>> >> > From jaroslav.bachorik at oracle.com Thu Feb 20 06:21:29 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 20 Feb 2014 15:21:29 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use Message-ID: <53060F69.7050704@oracle.com> Please, review this test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 Currently, the test is using two fixed ports to start JMX connector and RMI registry when necessary. It can not deal with situations when the ports are not available. The patch is adding the ability to obtain ports from the ephemeral range and use them instead of the hardcoded ones. It also tries to minimize the chance of another process stealing the ports by holding the corresponding SocketServers open till right before the port is actually needed. Thanks, -JB- From staffan.larsen at oracle.com Thu Feb 20 09:42:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 20 Feb 2014 18:42:05 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <53060F69.7050704@oracle.com> References: <53060F69.7050704@oracle.com> Message-ID: Looks good. You have a commented out call to debugPortUsage(pa); which you can remove before pushing. Thanks, /Staffan On 20 feb 2014, at 15:21, Jaroslav Bachorik wrote: > Please, review this test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 > Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 > > Currently, the test is using two fixed ports to start JMX connector and RMI registry when necessary. It can not deal with situations when the ports are not available. The patch is adding the ability to obtain ports from the ephemeral range and use them instead of the hardcoded ones. It also tries to minimize the chance of another process stealing the ports by holding the corresponding SocketServers open till right before the port is actually needed. > > Thanks, > > -JB- From shanliang.jiang at oracle.com Thu Feb 20 10:20:08 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Thu, 20 Feb 2014 19:20:08 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <53060F69.7050704@oracle.com> References: <53060F69.7050704@oracle.com> Message-ID: <53064758.7090009@oracle.com> Jaroslav, The failed tests were: 1, 7, 8, 9 but the tests using this port (port2: 50235) were 1, 3, 4, 6, 7, 8, 9 and tests 2,4,6 were passed. so I think that the problem might be that the port was not fully released when a test was trying to use it, even the port was closed by the previous test. Your solution is to create a Server socket on a free port, then release it when a test needs it. I suspect whether we will fall into same issue here: the port would not be fully released when using it? Shanliang Jaroslav Bachorik wrote: > Please, review this test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 > Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 > > Currently, the test is using two fixed ports to start JMX connector > and RMI registry when necessary. It can not deal with situations when > the ports are not available. The patch is adding the ability to obtain > ports from the ephemeral range and use them instead of the hardcoded > ones. It also tries to minimize the chance of another process stealing > the ports by holding the corresponding SocketServers open till right > before the port is actually needed. > > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Feb 20 23:35:30 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 21 Feb 2014 08:35:30 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <53064758.7090009@oracle.com> References: <53060F69.7050704@oracle.com> <53064758.7090009@oracle.com> Message-ID: <530701C2.1020003@oracle.com> Hi Shanliang, On 20.2.2014 19:20, shanliang wrote: > Jaroslav, > > The failed tests were: > 1, 7, 8, 9 > > but the tests using this port (port2: 50235) were > 1, 3, 4, 6, 7, 8, 9 > > and tests 2,4,6 were passed. > > so I think that the problem might be that the port was not fully > released when a test was trying to use it, even the port was closed by > the previous test. I don't think this is the case. Firstly, test 1 fails. There are no previous tests possibly holding on to the required port. So the port must have been taken by some foreign process. The port number being from the ephemeral range doesn't help either, quite contrary. Secondly, a port can not be partially bound - either a process binds to a port or not. Also, when a process exits all the bound ports must be released. Since we are waiting for the exit code of the launched test application before proceeding all the ports used by that application must be released before the main test routine can continue. > > Your solution is to create a Server socket on a free port, then release > it when a test needs it. I suspect whether we will fall into same issue > here: the port would not be fully released when using it? No. SocketServer.close() is called synchronously right before the port is going to be used. This call unbinds the socket and returns. At the moment of the return the port is free. I've run the tests locally and via JPRT and they are all passing. Thanks, -JB- > > Shanliang > > Jaroslav Bachorik wrote: >> Please, review this test fix. >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 >> >> Currently, the test is using two fixed ports to start JMX connector >> and RMI registry when necessary. It can not deal with situations when >> the ports are not available. The patch is adding the ability to obtain >> ports from the ephemeral range and use them instead of the hardcoded >> ones. It also tries to minimize the chance of another process stealing >> the ports by holding the corresponding SocketServers open till right >> before the port is actually needed. >> >> Thanks, >> >> -JB- > From shanliang.jiang at oracle.com Fri Feb 21 01:26:26 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 21 Feb 2014 10:26:26 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <530701C2.1020003@oracle.com> References: <53060F69.7050704@oracle.com> <53064758.7090009@oracle.com> <530701C2.1020003@oracle.com> Message-ID: <53071BC2.3060307@oracle.com> Jaroslav Bachorik wrote: > Hi Shanliang, > > On 20.2.2014 19:20, shanliang wrote: >> Jaroslav, >> >> The failed tests were: >> 1, 7, 8, 9 >> >> but the tests using this port (port2: 50235) were >> 1, 3, 4, 6, 7, 8, 9 >> >> and tests 2,4,6 were passed. >> >> so I think that the problem might be that the port was not fully >> released when a test was trying to use it, even the port was closed by >> the previous test. > > I don't think this is the case. > > Firstly, test 1 fails. There are no previous tests possibly holding on > to the required port. So the port must have been taken by some foreign > process. The port number being from the ephemeral range doesn't help > either, quite contrary. > > Secondly, a port can not be partially bound - either a process binds > to a port or not. Also, when a process exits all the bound ports must > be released. Since we are waiting for the exit code of the launched > test application before proceeding all the ports used by that > application must be released before the main test routine can continue. Why did exception "Port already in use error: " happen for Test1, then the port was free for 3/4/6, and then the exception appeared again for 7, 8, 9? A port is possibly unavailable after being closed, because it can be in the state TIME_WAIT. Your fix created a server socket but no client would connect to it, then the port could be available immediately after close(), not need to enter TIME_WAIT state, if so hopeful the fix could work. Shanliang > >> >> Your solution is to create a Server socket on a free port, then release >> it when a test needs it. I suspect whether we will fall into same issue >> here: the port would not be fully released when using it? > > No. SocketServer.close() is called synchronously right before the port > is going to be used. This call unbinds the socket and returns. At the > moment of the return the port is free. I've run the tests locally and > via JPRT and they are all passing. > > Thanks, > > -JB- > >> >> Shanliang >> >> Jaroslav Bachorik wrote: >>> Please, review this test fix. >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 >>> >>> Currently, the test is using two fixed ports to start JMX connector >>> and RMI registry when necessary. It can not deal with situations when >>> the ports are not available. The patch is adding the ability to obtain >>> ports from the ephemeral range and use them instead of the hardcoded >>> ones. It also tries to minimize the chance of another process stealing >>> the ports by holding the corresponding SocketServers open till right >>> before the port is actually needed. >>> >>> Thanks, >>> >>> -JB- >> > From jaroslav.bachorik at oracle.com Fri Feb 21 01:50:04 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 21 Feb 2014 10:50:04 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <53071BC2.3060307@oracle.com> References: <53060F69.7050704@oracle.com> <53064758.7090009@oracle.com> <530701C2.1020003@oracle.com> <53071BC2.3060307@oracle.com> Message-ID: <5307214C.2080009@oracle.com> On 21.2.2014 10:26, shanliang wrote: > Jaroslav Bachorik wrote: >> Hi Shanliang, >> >> On 20.2.2014 19:20, shanliang wrote: >>> Jaroslav, >>> >>> The failed tests were: >>> 1, 7, 8, 9 >>> >>> but the tests using this port (port2: 50235) were >>> 1, 3, 4, 6, 7, 8, 9 >>> >>> and tests 2,4,6 were passed. >>> >>> so I think that the problem might be that the port was not fully >>> released when a test was trying to use it, even the port was closed by >>> the previous test. >> >> I don't think this is the case. >> >> Firstly, test 1 fails. There are no previous tests possibly holding on >> to the required port. So the port must have been taken by some foreign >> process. The port number being from the ephemeral range doesn't help >> either, quite contrary. >> >> Secondly, a port can not be partially bound - either a process binds >> to a port or not. Also, when a process exits all the bound ports must >> be released. Since we are waiting for the exit code of the launched >> test application before proceeding all the ports used by that >> application must be released before the main test routine can continue. > Why did exception "Port already in use error: " happen for Test1, then > the port was free for 3/4/6, and then the exception appeared again for > 7, 8, 9? Test1: fails; it tries to start JMX connector on port 50235 and check the conenction afterward Test2: passes; does not use port 50235 Test3: passes; checks for not being able to connect to port 50235 Test4: fails; the same as Test1 Test5: passes; the same as Test2 Test6: fails; it tries to start RMI registry on port 50235 and fails Test7: fails; the same as Test1 Test8: fails; the same as Test1 Test9: fails; the same as Test1 Test10: passes; the same as Test2 Test11: passes; the same as Test2 Test12: passes; the same as Test2 Test13: passes; the same as Test2 The port doesn't mysteriously become used and unused. It is still occupied by a different process. Some of the tests don't fail simply because they don't use the port. > > A port is possibly unavailable after being closed, because it can be in > the state TIME_WAIT. > > Your fix created a server socket but no client would connect to it, then > the port could be available immediately after close(), not need to enter > TIME_WAIT state, if so hopeful the fix could work. SocketServer does not accept any incoming connection and as such the socket should not go to TIME_WAIT state when it is closed. The JPRT results would indicate that this is indeed the case. -JB- > > Shanliang >> >>> >>> Your solution is to create a Server socket on a free port, then release >>> it when a test needs it. I suspect whether we will fall into same issue >>> here: the port would not be fully released when using it? >> >> No. SocketServer.close() is called synchronously right before the port >> is going to be used. This call unbinds the socket and returns. At the >> moment of the return the port is free. I've run the tests locally and >> via JPRT and they are all passing. >> >> Thanks, >> >> -JB- >> >>> >>> Shanliang >>> >>> Jaroslav Bachorik wrote: >>>> Please, review this test fix. >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 >>>> >>>> Currently, the test is using two fixed ports to start JMX connector >>>> and RMI registry when necessary. It can not deal with situations when >>>> the ports are not available. The patch is adding the ability to obtain >>>> ports from the ephemeral range and use them instead of the hardcoded >>>> ones. It also tries to minimize the chance of another process stealing >>>> the ports by holding the corresponding SocketServers open till right >>>> before the port is actually needed. >>>> >>>> Thanks, >>>> >>>> -JB- >>> >> > From jaroslav.bachorik at oracle.com Fri Feb 21 02:13:39 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 21 Feb 2014 11:13:39 +0100 Subject: jmx-dev RFR 8033787: [TESTBUG] Few jdk regression management tests should be improved with -XX:+UsePerfData usage Message-ID: <530726D3.6020504@oracle.com> Please, review this very simple test fix. Issue : https://bugs.openjdk.java.net/browse/JDK-8033787 Webrev: http://cr.openjdk.java.net/~jbachorik/8033787/webrev.00 The fix just adds -XX:+UsePerfData parameter to the @run section of the mentioned test. -JB- From david.holmes at oracle.com Fri Feb 21 03:16:22 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 21 Feb 2014 21:16:22 +1000 Subject: jmx-dev RFR 8033787: [TESTBUG] Few jdk regression management tests should be improved with -XX:+UsePerfData usage In-Reply-To: <530726D3.6020504@oracle.com> References: <530726D3.6020504@oracle.com> Message-ID: <53073586.3050203@oracle.com> Looks okay to me. David On 21/02/2014 8:13 PM, Jaroslav Bachorik wrote: > Please, review this very simple test fix. > > Issue : https://bugs.openjdk.java.net/browse/JDK-8033787 > Webrev: http://cr.openjdk.java.net/~jbachorik/8033787/webrev.00 > > The fix just adds -XX:+UsePerfData parameter to the @run section of the > mentioned test. > > -JB- From shanliang.jiang at oracle.com Fri Feb 21 04:42:11 2014 From: shanliang.jiang at oracle.com (shanliang) Date: Fri, 21 Feb 2014 13:42:11 +0100 Subject: jmx-dev RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use In-Reply-To: <5307214C.2080009@oracle.com> References: <53060F69.7050704@oracle.com> <53064758.7090009@oracle.com> <530701C2.1020003@oracle.com> <53071BC2.3060307@oracle.com> <5307214C.2080009@oracle.com> Message-ID: <530749A3.7060802@oracle.com> Jaroslav Bachorik wrote: > On 21.2.2014 10:26, shanliang wrote: >> Jaroslav Bachorik wrote: >>> Hi Shanliang, >>> >>> On 20.2.2014 19:20, shanliang wrote: >>>> Jaroslav, >>>> >>>> The failed tests were: >>>> 1, 7, 8, 9 >>>> >>>> but the tests using this port (port2: 50235) were >>>> 1, 3, 4, 6, 7, 8, 9 >>>> >>>> and tests 2,4,6 were passed. >>>> >>>> so I think that the problem might be that the port was not fully >>>> released when a test was trying to use it, even the port was closed by >>>> the previous test. >>> >>> I don't think this is the case. >>> >>> Firstly, test 1 fails. There are no previous tests possibly holding on >>> to the required port. So the port must have been taken by some foreign >>> process. The port number being from the ephemeral range doesn't help >>> either, quite contrary. >>> >>> Secondly, a port can not be partially bound - either a process binds >>> to a port or not. Also, when a process exits all the bound ports must >>> be released. Since we are waiting for the exit code of the launched >>> test application before proceeding all the ports used by that >>> application must be released before the main test routine can continue. >> Why did exception "Port already in use error: " happen for Test1, then >> the port was free for 3/4/6, and then the exception appeared again for >> 7, 8, 9? > > Test1: fails; it tries to start JMX connector on port 50235 and check > the conenction afterward > Test2: passes; does not use port 50235 > Test3: passes; checks for not being able to connect to port 50235 > Test4: fails; the same as Test1 > Test5: passes; the same as Test2 > Test6: fails; it tries to start RMI registry on port 50235 and fails > Test7: fails; the same as Test1 > Test8: fails; the same as Test1 > Test9: fails; the same as Test1 > Test10: passes; the same as Test2 > Test11: passes; the same as Test2 > Test12: passes; the same as Test2 > Test13: passes; the same as Test2 > > The port doesn't mysteriously become used and unused. It is still > occupied by a different process. Some of the tests don't fail simply > because they don't use the port. Yes right, some tests passed because they did not expected JMX connection, not sure possible to distinguish between a port issue and no jmx server issue. The fix looks OK. Thanks, Shanliang > >> >> A port is possibly unavailable after being closed, because it can be in >> the state TIME_WAIT. >> >> Your fix created a server socket but no client would connect to it, then >> the port could be available immediately after close(), not need to enter >> TIME_WAIT state, if so hopeful the fix could work. > > SocketServer does not accept any incoming connection and as such the > socket should not go to TIME_WAIT state when it is closed. The JPRT > results would indicate that this is indeed the case. > > -JB- > >> >> Shanliang >>> >>>> >>>> Your solution is to create a Server socket on a free port, then >>>> release >>>> it when a test needs it. I suspect whether we will fall into same >>>> issue >>>> here: the port would not be fully released when using it? >>> >>> No. SocketServer.close() is called synchronously right before the port >>> is going to be used. This call unbinds the socket and returns. At the >>> moment of the return the port is free. I've run the tests locally and >>> via JPRT and they are all passing. >>> >>> Thanks, >>> >>> -JB- >>> >>>> >>>> Shanliang >>>> >>>> Jaroslav Bachorik wrote: >>>>> Please, review this test fix. >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8035395 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00 >>>>> >>>>> Currently, the test is using two fixed ports to start JMX connector >>>>> and RMI registry when necessary. It can not deal with situations when >>>>> the ports are not available. The patch is adding the ability to >>>>> obtain >>>>> ports from the ephemeral range and use them instead of the hardcoded >>>>> ones. It also tries to minimize the chance of another process >>>>> stealing >>>>> the ports by holding the corresponding SocketServers open till right >>>>> before the port is actually needed. >>>>> >>>>> Thanks, >>>>> >>>>> -JB- >>>> >>> >> >