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 <classpath>' which would result in
<classpath> 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-
