Staffan, Excuse me.
I didn't know about that.
I looked at the http://openjdk.java.net/census#serviceability.
Now I'm in need of the second review.
On 26.02.2014 18:36, Staffan Larsen wrote:
On 26 feb 2014, at 15:24, taras ledkov taras.led...@oracle.com wrote:
Hi,
Alan, Mandy could you
On 27.2.2014 12:39, taras ledkov wrote:
Staffan, Excuse me.
I didn't know about that.
I looked at the http://openjdk.java.net/census#serviceability.
Now I'm in need of the second review.
You only need one Reviewer to approve. The other approvals may come from
non-Reviewers.
-JB-
On
On 27 feb 2014, at 12:39, taras ledkov taras.led...@oracle.com wrote:
Staffan, Excuse me.
No problem.
I didn't know about that.
I looked at the http://openjdk.java.net/census#serviceability.
In this case the relevant project is jdk9 since that is where the change should
happen:
Hi,
Alan, Mandy could you please review the fix:
https://bugs.openjdk.java.net/browse/JDK-7195249.
I had the discussion with Jaroslav and Staffan and they have approved my
fix, but they are not reviewers.
Webrev for jdk part:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
On 26 feb 2014, at 15:24, taras ledkov taras.led...@oracle.com wrote:
Hi,
Alan, Mandy could you please review the fix:
https://bugs.openjdk.java.net/browse/JDK-7195249.
I had the discussion with Jaroslav and Staffan and they have approved my fix,
but they are not reviewers.
I am a
Thumbs up. (not a reviewer, though)
-JB-
On 19.2.2014 12:05, taras ledkov wrote:
Hi,
Imports are fixed:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
On 05.02.2014 17:20, Jaroslav Bachorik wrote:
Hi Taras,
thanks for taking care of this.
The changes look fine to me.
One
Hi,
Imports are fixed:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
On 05.02.2014 17:20, Jaroslav Bachorik wrote:
Hi Taras,
thanks for taking care of this.
The changes look fine to me.
One minor nit is unused imports of the library classes in
Hi,
So please take a look at the review against JDK9.
The reviewed patch had not been integrated into JDK8.
Port to JDK9 is identical. The difference: the ProcessTools.java has
been already patched by Jaroslav.
Webrev for jdk part:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.03/
Hi Taras,
thanks for taking care of this.
The changes look fine to me.
One minor nit is unused imports of the library classes in
test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java.
It does not use any of those classes as its base class
AbstractFilePermissionTest does
Hi Jaroslav,
Could you please review the last changes?
Are you OK?
On 20.01.2014 19:21, Staffan Larsen wrote:
Sorry for not replying earlier. Yes, I’m ok with these changes.
Thanks,
/Staffan
On 20 jan 2014, at 16:07, taras ledkov taras.led...@oracle.com wrote:
Hi Staffan,
I fixed the
Hi Taras,
On 21.1.2014 10:30, taras ledkov wrote:
Hi Jaroslav,
Could you please review the last changes?
Are you OK?
Yes, the change looks ok. But I think we will need to get back to this
problem eventually and implement a central port dispatcher if we want to
be 100% sure the port
Hi Staffan,
I fixed the tests according with your comments.
Are you OK?
On 15.01.2014 19:15, taras ledkov wrote:
Hi,
Please take a look at the new review.
Webrev for jdk part:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/
Webrev for hs part:
Sorry for not replying earlier. Yes, I’m ok with these changes.
Thanks,
/Staffan
On 20 jan 2014, at 16:07, taras ledkov taras.led...@oracle.com wrote:
Hi Staffan,
I fixed the tests according with your comments.
Are you OK?
On 15.01.2014 19:15, taras ledkov wrote:
Hi,
Please take a
Hi,
Please take a look at the new review.
Webrev for jdk part:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/
Webrev for hs part:
http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/
My answers are inline:
On 08.01.2014 17:46, Staffan Larsen wrote:
Hi Taras,
Thanks for
Hi Taras,
Thanks for doing this clean up and conversion of tests into Java. Here’s a
couple of comments:
test/runtime/6294277/SourceDebugExtension.java:
This test could be simplified by not specifying an address at all. Since the
test never connects to the JVM started with -Xrunjdwp, there is
Hi,
Please take a look at the review with fixed issues about trying to
launch test that needs free port several times.
Webrev for jdk part:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/
Webrev for hs part:
http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/
Pay your
Hi,
I've consulted with Serviceability engineers (add them to CC list) and
they would like to see tests to solve these problem so far:
2. Implement loops in every test.
Thanks,
Katja
On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote:
Guys.
Let me try to sum up what was said before
Guys.
Let me try to sum up what was said before and may be suggest a compromise.
1. There is a desire to have a support port allocation on the level of a
JTReg suite execution. Taras created a bug for that
(https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it is a test
harness API
Taras,
I agree with the previous comments, that Utils.getFreePort() does not
guarantee the port will be still free when you start your process.
Unfortunately I don't think the library can do more. However, there is a
solution.
Please, look at the *jdk/test/sun/tools/jstatd/JstatdTest.java
Hi Everyone,
Whatever logic is to be chosen to select a free port, it is the library
responsibility to implements it, would not you agree?
Hence what I am suggesting is to integrate the tests as is.
Should we decide to replace logic of the port selection, we could do it
later in the
On 20.11.2013 18:38, Dmitry Samersoff wrote:
Roger,
As soon as we close a socket nobody can guarantee that the port is free.
Moreover, port returned by getFreePort()[1] remains not accessible for
some time - it depends to system setup, take a look to discussions
around SO_REUSEPORT for Linux
Taras,
*The only* correct way to take really free port is:
1. Chose random number between 49152 and 65535
2. Open socket
if socket fails - repeat step 1
if socket OK - return *socket*
If you can't keep the socket open (e.g. you have to pass port number as
property value) you shouldn't do any
On 20.11.2013 14:04, Dmitry Samersoff wrote:
Taras,
*The only* correct way to take really free port is:
1. Chose random number between 49152 and 65535
2. Open socket
if socket fails - repeat step 1
if socket OK - return *socket*
If you can't keep the socket open (e.g. you have to pass port
Jaroslav,
Generally speacking - test getting port number from command line should
get it from harness and harness have to maintain a pool of free ports.
But it's a long term goal.
Today we don't have better option than chose a random number and hope
this port is free.
Any pre-check just
Hi,
fyi, The jdk.testlibrary.Utils.getFreePort() method will Open an free
Socket, close it and return
the port number.
And as Alan recommended, use (0) when possible to have the system assign
the port #.
Roger
On 11/20/2013 8:04 AM, Dmitry Samersoff wrote:
Taras,
*The only* correct way
Roger,
As soon as we close a socket nobody can guarantee that the port is free.
Moreover, port returned by getFreePort()[1] remains not accessible for
some time - it depends to system setup, take a look to discussions
around SO_REUSEPORT for Linux or SO_REUSEADDR and SO_LINGER for BSD.
So from
26 matches
Mail list logo
