ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

[Eric Wang]

Hi,

This is a review request to remove the test 
java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test tracked 
by JDK-7079145  is 
hung if linux kernel is 2.6.18.

By upgrading the kernel to higher version 2.6.32, the problem doesn't exist.

Thanks,
Eric

ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

[Eric Wang]

Hi,

This is a review request to remove the test 
java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test tracked 
by JDK-7079145  is 
hung if linux kernel is 2.6.18.

By upgrading the kernel to higher version 2.6.32, the problem doesn't exist.
http://cr.openjdk.java.net/~ewang/7079145/webrev.00/ 



Thanks,
Eric

Re: ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

[Eric Wang]

On 2013/10/24 10:57, Eric Wang wrote:

Hi,

This is a review request to remove the test 
java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test tracked 
by JDK-7079145 <https://bugs.openjdk.java.net/browse/JDK-7079145> is 
hung if linux kernel is 2.6.18.
By upgrading the kernel to higher version 2.6.32, the problem doesn't 
exist.


Thanks,
Eric

Sorry, forgot to update the webrev:
http://cr.openjdk.java.net/~ewang/7079145/webrev.00/ 
<http://cr.openjdk.java.net/%7Eewang/7079145/webrev.00/>


Thanks,
Eric

Re: ProblemList updating request for JDK-7079145: java/net/ipv6tests/UdpTest.java

[Eric Wang]

Thanks Alan & Chris for review and pushing code.

-Eric
On 2013/10/24 20:59, Chris Hegarty wrote:

The changes, to remove this test from the problem list, look fine to me.

I see that JDK-7079145 has been closed. We should probably re-open it, 
and use it to push these changes.


I can sponsor this change for you.

-Chris.

On 10/24/2013 03:58 AM, Eric Wang wrote:

Hi,

This is a review request to remove the test
java/net/ipv6tests/UdpTest.java from ProblemList.txt. The test tracked
by JDK-7079145 <https://bugs.openjdk.java.net/browse/JDK-7079145> is
hung if linux kernel is 2.6.18.
By upgrading the kernel to higher version 2.6.32, the problem doesn't 
exist.

http://cr.openjdk.java.net/~ewang/7079145/webrev.00/
<http://cr.openjdk.java.net/%7Eewang/7079145/webrev.00/>

Thanks,
Eric
<https://bugs.openjdk.java.net/browse/JDK-7079145>

Re: RFR for bug JDK-8035633 TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently

[Eric Wang]

On 2014/2/25 16:59, Alan Bateman wrote:

On 25/02/2014 08:49, Eric Wang wrote:

Hi Everyone,

I'm working on the test bug 
https://bugs.openjdk.java.net/browse/JDK-8035633, There are 4 tests 
(one is in a closed test) failed due to NullPointerException.
All tests failed at similar places "if (isWindows && 
ni.getDisplayName().contains("Teredo"))", the root cause is the 
NetworkInterface may return null if no display name is available.
so the fix is to make sure the display name is not null before 
calling the method "contains("Teredo")", something like "if 
(isWindows && displayName != null && displayName.contains("Teredo"))"


Please let me know if you have any comment. The webrev will be sent 
after internal review.
Yes, NetworkInterface's getDisplyName is allowed to return null and it 
looks like this wasn't taken into account when these tests were 
changed via JDK-8022963 to skip tunnels. Once you have a patch then 
net-dev would be the best list to bring it to.


-Alan.


Thanks Alan to suggest the correct alias!
Below is the webrev for this bug, Can you or anyone else help to review 
the fix?
http://cr.openjdk.java.net/~ewang/JDK-8035633/webrev.00/ 
<http://cr.openjdk.java.net/%7Eewang/JDK-8035633/webrev.00/>


There is one more closed test fixed, it will be sent in another mail.

Thanks,
Eric

Re: RFR for bug JDK-8035633 TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently

[Eric Wang]

Hi Ivan & Chris,

Thank you for the comments. I have corrected the typo in the comment and 
reverted the year of copyright. Please help to review it again.
http://cr.openjdk.java.net/~ewang/JDK-8035633/webrev.01/ 
<http://cr.openjdk.java.net/%7Eewang/JDK-8035633/webrev.01/>


Chris, Could you please be my sponsor to push the fix, if it looks OK.

Thanks a lot!
Eric
On 2014/2/27 17:48, Ivan Gerasimov wrote:

Hello Eric

Would you please also correct the comment on the line above your change:
s/seudo/pseudo/

The typo is in all three files.

Sincerely yours,
Ivan


On 27.02.2014 12:18, Eric Wang wrote:

On 2014/2/25 16:59, Alan Bateman wrote:

On 25/02/2014 08:49, Eric Wang wrote:

Hi Everyone,

I'm working on the test bug 
https://bugs.openjdk.java.net/browse/JDK-8035633, There are 4 tests 
(one is in a closed test) failed due to NullPointerException.
All tests failed at similar places "if (isWindows && 
ni.getDisplayName().contains("Teredo"))", the root cause is the 
NetworkInterface may return null if no display name is available.
so the fix is to make sure the display name is not null before 
calling the method "contains("Teredo")", something like "if 
(isWindows && displayName != null && displayName.contains("Teredo"))"


Please let me know if you have any comment. The webrev will be sent 
after internal review.
Yes, NetworkInterface's getDisplyName is allowed to return null and 
it looks like this wasn't taken into account when these tests were 
changed via JDK-8022963 to skip tunnels. Once you have a patch then 
net-dev would be the best list to bring it to.


-Alan.


Thanks Alan to suggest the correct alias!
Below is the webrev for this bug, Can you or anyone else help to 
review the fix?
http://cr.openjdk.java.net/~ewang/JDK-8035633/webrev.00/ 
<http://cr.openjdk.java.net/%7Eewang/JDK-8035633/webrev.00/>


There is one more closed test fixed, it will be sent in another mail.

Thanks,
Eric

RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

[Eric Wang]

Hi everyone,

Hi Everyone,

I'm working on the test bug 
https://bugs.openjdk.java.net/browse/JDK-8025209, The test uses 
Thread.sleep to sync-up threads which is not a correct assumption. The 
fix is just to sync-up 2 threads using proper way.


The webrev will be sent after internal review. Please let me know if you 
have any comment.


Thanks,
Eric

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

[Eric Wang]

Hi Chris & All,

Sorry that the fix spent a bit long time for internal review.
Can you please review the fix below for bug JDK-8025209 
<https://bugs.openjdk.java.net/browse/JDK-8025209>. The fix is just to 
make the thread synchronization is more robust and made some cleanup.

http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/

Thanks,
Eric
On 2014/3/5 18:01, Chris Hegarty wrote:

On 5 Mar 2014, at 09:48, Eric Wang  wrote:


Hi everyone,

Hi Everyone,

I'm working on the test bug https://bugs.openjdk.java.net/browse/JDK-8025209, 
The test uses Thread.sleep to sync-up threads which is not a correct 
assumption. The fix is just to sync-up 2 threads using proper way.

The webrev will be sent after internal review. Please let me know if you have 
any comment.

This test is part of the OpenJDK source. Please just post your webrev 
externally for review.

Thanks,
-Chris.


Thanks,
Eric

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

[Eric Wang]

Hi Chris,

I have updated the webrev according to your suggestions. Can you please 
review it again?

http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/

Thanks to review the fix and sponsor it for me.
-Eric

On 2014/3/28 18:41, Chris Hegarty wrote:

Hi Eric,

I've taken a look at the webrev and I mainly agree with the 
changes/refactoring.


On the issue of increasing the timeout to 20 secs; there is a clear 
race in this test, and your refactoring has reduced it as much as 
possible. Since the sleep will always occur, I would prefer to reduce 
it from 20 secs to 5 secs. That, in combination with your use of a 
latch, should be sufficient.


Also, there is a variant of each test that runs with a 5,000 
millisecond timeout. This timeout should be increased to 20,000 
milliseconds. Otherwise, the blocking IO call may timeout rather than 
be interrupted ( which is what the test is testing for ).


If you address the above issues, I will be happy to sponsor this 
change for you.


-Chris.

On 28/03/14 05:54, Eric Wang wrote:

Hi Chris & All,

Sorry that the fix spent a bit long time for internal review.
Can you please review the fix below for bug JDK-8025209
<https://bugs.openjdk.java.net/browse/JDK-8025209>. The fix is just to
make the thread synchronization is more robust and made some cleanup.
http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/

Thanks,
Eric
On 2014/3/5 18:01, Chris Hegarty wrote:

On 5 Mar 2014, at 09:48, Eric Wang  wrote:


Hi everyone,

Hi Everyone,

I'm working on the test 
bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses 
Thread.sleep to sync-up threads which is not a correct assumption. 
The fix is just to sync-up 2 threads using proper way.


The webrev will be sent after internal review. Please let me know 
if you have any comment.
This test is part of the OpenJDK source. Please just post your 
webrev externally for review.


Thanks,
-Chris.


Thanks,
Eric

Re: RFR for bug JDK-8025209 Intermittent test failure: java/net/Socket/asyncClose/AsyncClose.java

[Eric Wang]

Hi Chris,

Thanks for the push. I'm glad to learn the modern way from your refactor.

- Cheers,
Eric
On 2014/3/31 18:37, Chris Hegarty wrote:

Thanks Eric,

Pushed
  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e0d1a825848f

There was a small issue of secs vs millis. Your webrev used 5 millis 
as a sleep rather than 5000. I fixed this before pushing.


Also, with the changes the time for the test increased so I trivially 
added a change to have the various socket type checks run in parallel. 
With this the run time of the test is half of that of the original test.


-Chris.


On 30/03/14 03:55, Eric Wang wrote:

Hi Chris,

I have updated the webrev according to your suggestions. Can you please
review it again?
http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.01/

Thanks to review the fix and sponsor it for me.
-Eric

On 2014/3/28 18:41, Chris Hegarty wrote:

Hi Eric,

I've taken a look at the webrev and I mainly agree with the
changes/refactoring.

On the issue of increasing the timeout to 20 secs; there is a clear
race in this test, and your refactoring has reduced it as much as
possible. Since the sleep will always occur, I would prefer to reduce
it from 20 secs to 5 secs. That, in combination with your use of a
latch, should be sufficient.

Also, there is a variant of each test that runs with a 5,000
millisecond timeout. This timeout should be increased to 20,000
milliseconds. Otherwise, the blocking IO call may timeout rather than
be interrupted ( which is what the test is testing for ).

If you address the above issues, I will be happy to sponsor this
change for you.

-Chris.

On 28/03/14 05:54, Eric Wang wrote:

Hi Chris & All,

Sorry that the fix spent a bit long time for internal review.
Can you please review the fix below for bug JDK-8025209
<https://bugs.openjdk.java.net/browse/JDK-8025209>. The fix is just to
make the thread synchronization is more robust and made some cleanup.
http://cr.openjdk.java.net/~ewang/JDK-8025209/webrev.00/

Thanks,
Eric
On 2014/3/5 18:01, Chris Hegarty wrote:

On 5 Mar 2014, at 09:48, Eric Wang  wrote:


Hi everyone,

Hi Everyone,

I'm working on the test
bughttps://bugs.openjdk.java.net/browse/JDK-8025209, The test uses
Thread.sleep to sync-up threads which is not a correct assumption.
The fix is just to sync-up 2 threads using proper way.

The webrev will be sent after internal review. Please let me know
if you have any comment.

This test is part of the OpenJDK source. Please just post your
webrev externally for review.

Thanks,
-Chris.


Thanks,
Eric

[PATCH] Review Request for bug 7032247 java/net/InetAddress/GetLocalHostWithSM.java fails if hostname resolves to loopback address

[Eric Wang]

Hi All,

Please help to review the fix below for bug 7032247 
.

http://dl.dropbox.com/u/90659131/fixes/7032247/webrev/index.html

As discussed, the test should pass silently if on Linux the local host 
name is resolved to loopback address.


Thanks,
Eric