Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Tristan Yan]

Sorry, you're right. Change to 4000 means tolerance will be 2000ms to 
6000ms.  And timeout will be 6000ms.

Thank you for sponsor this.
Tristan

On 01/17/2014 07:45 PM, Chris Hegarty wrote:


On 17/01/14 11:24, Tristan Yan wrote:

Shall we adjust runAfter time a little bigger also if you're doing this.
Because if network is fast enough. All thing could be finished less than
3000 ms


No, this is just a wait/delay time before sending the packet. A simple 
update to the expected time, 2000 -> 4000, should be sufficient.


-Chris.


Thank you
Tristan

On 01/17/2014 07:20 PM, Chris Hegarty wrote:

Oh, we should really increase the acceptable expected time in the
subsequent checkTime call. From say 2000 -> 4000.

If you agree, I will make the change before pushing on your behalf.

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Tristan Yan]

Shall we adjust runAfter time a little bigger also if you're doing this. 
Because if network is fast enough. All thing could be finished less than 
3000 ms

Thank you
Tristan

On 01/17/2014 07:20 PM, Chris Hegarty wrote:
Oh, we should really increase the acceptable expected time in the 
subsequent checkTime call. From say 2000 -> 4000.


If you agree, I will make the change before pushing on your behalf. 

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Tristan Yan]

Thank you
Tristan

On 01/17/2014 06:48 PM, Chris Hegarty wrote:

On 17/01/14 10:39, Tristan Yan wrote:

Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/


Thanks, approved. I can sponsor this change for you.

-Chris.


Thank you
Tristan

On 01/17/2014 06:32 PM, Chris Hegarty wrote:

The bug shows the following stacktrace:

  --System.err:(16/903)--
java.net.SocketTimeoutException: Receive timed out
at
java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native 


Method)
at
java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109) 


at java.net.DatagramSocket.receive(DatagramSocket.java:721)
at UdpTest.test2(UdpTest.java:159)
at UdpTest.main(UdpTest.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) 


at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 


at java.lang.reflect.Method.invoke(Method.java:483)
at
com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746) 


at java.lang.Thread.run(Thread.java:744)


So the failure was not related to the initial two receives that are
expected to timeout. 4000 millis should be sufficient for these.

The failure looks like it is because the third receive, that is
expected to NOT timeout, does timeout. The socket timeout value is
still set, in the original code, to 4000 millis. It should be more
efficient to simply increase the timeout of the socket just before the
third received, to say 1 millis.

Make sense?

-Chris.


On 17/01/14 05:40, Tristan Yan wrote:

Hi All

Please review the simple code fix for JDK-8031666.

http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/

This test fails in very small chance. Adding socket timeout a little
bigger.

Thank you

Tristan

Re: RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Tristan Yan]

Agree, reset timeout should be better move
http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.01/
Thank you
Tristan

On 01/17/2014 06:32 PM, Chris Hegarty wrote:

The bug shows the following stacktrace:

  --System.err:(16/903)--
java.net.SocketTimeoutException: Receive timed out
at 
java.net.DualStackPlainDatagramSocketImpl.socketReceiveOrPeekData(Native 
Method)
at 
java.net.DualStackPlainDatagramSocketImpl.peekData(DualStackPlainDatagramSocketImpl.java:109)

at java.net.DatagramSocket.receive(DatagramSocket.java:721)
at UdpTest.test2(UdpTest.java:159)
at UdpTest.main(UdpTest.java:72)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:483)
at 
com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:746)

at java.lang.Thread.run(Thread.java:744)


So the failure was not related to the initial two receives that are 
expected to timeout. 4000 millis should be sufficient for these.


The failure looks like it is because the third receive, that is 
expected to NOT timeout, does timeout. The socket timeout value is 
still set, in the original code, to 4000 millis. It should be more 
efficient to simply increase the timeout of the socket just before the 
third received, to say 1 millis.


Make sense?

-Chris.


On 17/01/14 05:40, Tristan Yan wrote:

Hi All

Please review the simple code fix for JDK-8031666.

http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/

This test fails in very small chance. Adding socket timeout a little 
bigger.


Thank you

Tristan

RFR for JDK-8031666: TEST_BUG: java/net/ipv6tests/UdpTest.java failed because of SocketTimeoutException

[Tristan Yan]

Hi All

Please review the simple code fix for JDK-8031666.

http://cr.openjdk.java.net/~tyan/JDK-8031666/webrev.00/

This test fails in very small chance. Adding socket timeout a little bigger.

Thank you

Tristan

Close request for JDK-8022211

[Tristan Yan]

Hi All

I am working on https://bugs.openjdk.java.net/browse/JDK-8022211. This 
test had failed a couple of times before JDK 8 build b79. But it has not 
failed since then. We performed repeated test runs  on the same machine 
that caused the latest failure for this test and we also tried same jdk 
binaries run for all regression tests, and were unable to reproduce the 
issue.


Given these conditions, I am going to close the bug as Not Reproducible. 
Let me know if anyone has any objection.


Thank you very much.

Tristan

答复: RFR for JDK-8022212 Intermittent test failures in java/net

[Tristan Yan]

Hi Chris
I don't see this has been pushed, could you do this for me.
Thank you very much.
Tristan

-邮件原件-
发件人: Tristan Yan 
发送时间: Saturday, November 16, 2013 11:25 AM
收件人: Chris Hegarty; net-dev@openjdk.java.net
主题: 答复: RFR for JDK-8022212 Intermittent test failures in java/net

Thanks Chris for sponsoring this.
Tristan

-邮件原件-
发件人: Chris Hegarty
发送时间: Thursday, November 14, 2013 9:34 PM
收件人: Tristan Yan; net-dev@openjdk.java.net
主题: Re: RFR for JDK-8022212 Intermittent test failures in java/net

Thank you Tristan. I can sponsor this change for you.

-Chris.

On 13/11/13 12:53, Tristan Yan wrote:
> Thank you Chris
> This is the webrev
> http://cr.openjdk.java.net/~ewang/tristan/JDK-8022212/webrev.00/
> Thank you
> Tristan
>
> On 11/13/2013 06:07 PM, Chris Hegarty wrote:
>> On 11/13/2013 06:00 AM, Tristan Yan wrote:
>>> Hi Everyone
>>>
>>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212.
>>> This is the same root cause as bug JDK-8022963, which is we should 
>>> not test "Teredo Tunneling Pseudo-Interface "  interface in windows.
>>> So suggested fix is doing the same as we did in JDK-8022963, remove 
>>> "Teredo Tunneling Pseudo-Interface " from this test.
>>> Please let me know if you have any comments or suggestions.
>>
>> If you have confirmed that these tests are failing for the same 
>> reason, then I think it is reasonable to apply similar changes to 
>> that of 8022963. Webrev?
>>
>> Thanks,
>> -Chris.
>>
>>>
>>> Tristan/
>>> /
>

答复: 答复: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

[Tristan Yan]

Oops, I must have bumped my head.
Thanks for point this out.
http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/
Tristan

-邮件原件-
发件人: Daniel Fuchs 
发送时间: Wednesday, November 20, 2013 8:12 PM
收件人: Tristan Yan; Chris Hegarty; net-dev@openjdk.java.net
主题: Re: 答复: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails 
intermittently

On 11/20/13 12:42 PM, Tristan Yan wrote:
> Thanks Chris and Daniel
> I change 'clientCtx' to final and error with volatile.

Unless I'm mistaken this should not compile because of line 60:

   44 static final SSLContext clientCtx = null;
   ...
   60 clientCtx = new 
SimpleSSLContext(System.getProperty("test.src")).get();

best regards,

-- daniel


> http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/
> I'm appreciated Chris be my sponsor for this.
> Thank you.
> Tristan
>
> -邮件原件-
> 发件人: Chris Hegarty
> 发送时间: Wednesday, November 20, 2013 6:49 PM
> 收件人: Daniel Fuchs; Tristan Yan; net-dev@openjdk.java.net
> 主题: Re: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java 
> fails intermittently
>
> On 20/11/13 10:19, Daniel Fuchs wrote:
>> Hi Tristan,
>>
>> I believe you should also declare the 'error' flag as well as the 
>> 'clientCtx' variable volatile since they are set by a thread and read 
>> by another.
>
> Good catch Daniel. Tristan, can you update the webrev and create a changeset. 
> I can then sponsor this change for you.
>
> Thanks,
> -Chris.
>
>
>
>>
>> best regards,
>>
>> -- daniel
>>
>> On 11/20/13 5:59 AM, Tristan Yan wrote:
>>> /Hi All/
>>>
>>> /I am working on https://bugs.openjdk.java.net/browse/JDK-703,
>>> this bug was opened 3 years ago and test was put into ProblemList. I 
>>> ran a
>>> 1000 times loop to try to reproduce the failure but I got no luck.
>>> Also I use same jdk binaries run all regression tests a couple of 
>>> hundred time I don’t see any failure on this test either./
>>>
>>> /I suggest we bring this test back from ProblemList and add a debug 
>>> info for only possible failure place./
>>>
>>> //
>>>
>>> /http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00//
>>>
>>> //
>>>
>>> /Please let me know if you have any suggestion or comments./
>>>
>>> //
>>>
>>> /Tristan Yan(Haibo Yan)/
>>>
>>> //
>>>
>>

答复: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

[Tristan Yan]

Thanks Chris and Daniel
I change 'clientCtx' to final and error with volatile.
http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00/
I'm appreciated Chris be my sponsor for this.
Thank you.
Tristan

-邮件原件-
发件人: Chris Hegarty 
发送时间: Wednesday, November 20, 2013 6:49 PM
收件人: Daniel Fuchs; Tristan Yan; net-dev@openjdk.java.net
主题: Re: RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails 
intermittently

On 20/11/13 10:19, Daniel Fuchs wrote:
> Hi Tristan,
>
> I believe you should also declare the 'error' flag as well as the 
> 'clientCtx' variable volatile since they are set by a thread and read 
> by another.

Good catch Daniel. Tristan, can you update the webrev and create a changeset. I 
can then sponsor this change for you.

Thanks,
-Chris.



>
> best regards,
>
> -- daniel
>
> On 11/20/13 5:59 AM, Tristan Yan wrote:
>> /Hi All/
>>
>> /I am working on https://bugs.openjdk.java.net/browse/JDK-703, 
>> this bug was opened 3 years ago and test was put into ProblemList. I 
>> ran a
>> 1000 times loop to try to reproduce the failure but I got no luck. 
>> Also I use same jdk binaries run all regression tests a couple of 
>> hundred time I don’t see any failure on this test either./
>>
>> /I suggest we bring this test back from ProblemList and add a debug 
>> info for only possible failure place./
>>
>> //
>>
>> /http://cr.openjdk.java.net/~ewang/tristan/JDK-703/webrev.00//
>>
>> //
>>
>> /Please let me know if you have any suggestion or comments./
>>
>> //
>>
>> /Tristan Yan(Haibo Yan)/
>>
>> //
>>
>

RFR for JDK-703666 test/com/sun/net/httpserver/Test9a.java fails intermittently

[Tristan Yan]

Hi All

I am working on https://bugs.openjdk.java.net/browse/JDK-703, this bug was 
opened 3 years ago and test was put into ProblemList. I ran a 1000 times loop 
to try to reproduce the failure but I got no luck. Also I use same jdk binaries 
run all regression tests a couple of hundred time I don't see any failure on 
this test either.

I suggest we bring this test back from ProblemList and add a debug info for 
only possible failure place.

 

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

 

Please let me know if you have any suggestion or comments.

 

Tristan Yan(Haibo Yan)

 

答复: RFR for JDK-8022212 Intermittent test failures in java/net

[Tristan Yan]

Thanks Chris for sponsoring this.
Tristan

-邮件原件-
发件人: Chris Hegarty 
发送时间: Thursday, November 14, 2013 9:34 PM
收件人: Tristan Yan; net-dev@openjdk.java.net
主题: Re: RFR for JDK-8022212 Intermittent test failures in java/net

Thank you Tristan. I can sponsor this change for you.

-Chris.

On 13/11/13 12:53, Tristan Yan wrote:
> Thank you Chris
> This is the webrev
> http://cr.openjdk.java.net/~ewang/tristan/JDK-8022212/webrev.00/
> Thank you
> Tristan
>
> On 11/13/2013 06:07 PM, Chris Hegarty wrote:
>> On 11/13/2013 06:00 AM, Tristan Yan wrote:
>>> Hi Everyone
>>>
>>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212.
>>> This is the same root cause as bug JDK-8022963, which is we should 
>>> not test "Teredo Tunneling Pseudo-Interface "  interface in windows.
>>> So suggested fix is doing the same as we did in JDK-8022963, remove 
>>> "Teredo Tunneling Pseudo-Interface " from this test.
>>> Please let me know if you have any comments or suggestions.
>>
>> If you have confirmed that these tests are failing for the same 
>> reason, then I think it is reasonable to apply similar changes to 
>> that of 8022963. Webrev?
>>
>> Thanks,
>> -Chris.
>>
>>>
>>> Tristan/
>>> /
>

RFR for JDK-7086879 java/net/InetAddress/CheckJNI.java hangs on Linux when IPv6 enabled

[Tristan Yan]

Hi Everyone

 

I am working on https://bugs.openjdk.java.net/browse/JDK-7086879 . The issue is 
seen on machines which have kernel version older than 2.6.18. The test was put 
on ProblemList.txt. From Michael's comments on 05 Nov, it looks like JPRT is 
fixed and the test runs successfully. We have upgraded 5 of 26 SQE machines 
which had similar issues and the test works fine for SQE as well. Once Michael 
confirms that he is fine with removing this test from ProblemList.txt, I will 
send out a webrev with the change.

 

Please let me know if you have any suggestions or comments.

 

Thank you.

 

 

Tristan Yan(Haibo Yan)

 

Re: RFR for JDK-8022212 Intermittent test failures in java/net

[Tristan Yan]

Thank you Chris
This is the webrev
http://cr.openjdk.java.net/~ewang/tristan/JDK-8022212/webrev.00/
Thank you
Tristan

On 11/13/2013 06:07 PM, Chris Hegarty wrote:

On 11/13/2013 06:00 AM, Tristan Yan wrote:

Hi Everyone

I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212.
This is the same root cause as bug JDK-8022963, which is we should not
test "Teredo Tunneling Pseudo-Interface "  interface in windows.
So suggested fix is doing the same as we did in JDK-8022963, remove
"Teredo Tunneling Pseudo-Interface " from this test.
Please let me know if you have any comments or suggestions.


If you have confirmed that these tests are failing for the same 
reason, then I think it is reasonable to apply similar changes to that 
of 8022963. Webrev?


Thanks,
-Chris.



Tristan/
/

RFR for JDK-8022212 Intermittent test failures in java/net

[Tristan Yan]

Hi Everyone

I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022212.
This is the same root cause as bug JDK-8022963, which is we should not 
test "Teredo Tunneling Pseudo-Interface "  interface in windows.
So suggested fix is doing the same as we did in JDK-8022963, remove 
"Teredo Tunneling Pseudo-Interface " from this test.

Please let me know if you have any comments or suggestions.

Tristan/
/

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

[Tristan Yan]

Hi Chris
I didn't this has been pushed, can you sponsor this for me.
Thank you so much
Tristan

On Nov 5, 2013, at 2:40 AM, Chris Hegarty  wrote:

> 
> On 01/11/2013 14:43, Tristan Yan wrote:
>> Hi everyone
>> Please review the fix for JDK-8022963.
>> 
>> http://cr.openjdk.java.net/~pzhang/Tristan/8022963/webrev/
> 
> This is not pretty, but I don't have a better alternative.
> 
> Any objections? Otherwise, I can help sponsor this.
> 
> -Chris.
> 
>> Description:
>> Since windows API has very inconsistent behavior on Teredo Tunneling
>> Pesudo-Interface, we removed this network interface for this test.
>> 
>> Thank you.
>> Tristan
>> 
>> On 01/11/2013 22:43, Chris Hegarty wrote:
>>> Hi Tristan,
>>> 
>>> From what I understand of the issue I see no problem with what you are
>>> suggesting. Webrev?
>>> 
>>> -Chris.
>>> 
>>> On 01/11/2013 05:44, Tristan Yan wrote:
>>>> Hi Everyone
>>>> 
>>>> I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022963.
>>>> Root cause for this bug is Windows API has inconsistent behavior for
>>>> Teredo Tunneling Interface, based on the discussion with Chris Hegarty,
>>>> we decided to fix this test with removing "Windows && Teredo Tunneling
>>>> Pseudo-Interface" from this test.
>>>> 
>>>> Please let me know if you have any comments or suggestions.
>>>> 
>>>> Thank you
>>>> 
>>>> Tristan
>>>> 
>>>> /Tristan Yan(Haibo Yan)/
>>>> 
>>>> /Office : 8610-61066212/
>>>> 
>>>> /Fax : 8610-61065441/
>>>> 
>>>> /Cell : 86-18610696822/
>>>> 
>>>> //
>>>> 
>>>> /2F, Building No. 24, Zhongguancun Software Park/
>>>> 
>>>> /Haidian District Beijing
>>>> <http://people.us.oracle.com/pls/oracle/f?p=8000:6:396067987304343:::6:P6_CITY:Beijing>
>>>> 
>>>> , 100193/
>>>> 
>>>> oracle
>>>> 
>> 

RFR for JDK-8023462: TEST_BUG: test/com/sun/net/httpserver/bugs/B6433018.java fails on slow/single core machine

[Tristan Yan]

Hi Everyone

Please review the fix for JDK-8023462 
.


Description:
This test is using Thread.sleep(3000) to sync between server and client, 
this could be wrong when running is slow machine. I am trying to use 
modern CountDownLatch sync server and client.


http://cr.openjdk.java.net/~pzhang/Tristan/8023462/webrev/

Thank you
Tristan

Re: RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

[Tristan Yan]

Hi everyone
Please review the fix for JDK-8022963.

http://cr.openjdk.java.net/~pzhang/Tristan/8022963/webrev/

Description:
Since windows API has very inconsistent behavior on Teredo Tunneling 
Pesudo-Interface, we removed this network interface for this test.


Thank you.
Tristan

On 01/11/2013 22:43, Chris Hegarty wrote:

Hi Tristan,

From what I understand of the issue I see no problem with what you are 
suggesting. Webrev?


-Chris.

On 01/11/2013 05:44, Tristan Yan wrote:

Hi Everyone

I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022963.
Root cause for this bug is Windows API has inconsistent behavior for
Teredo Tunneling Interface, based on the discussion with Chris Hegarty,
we decided to fix this test with removing "Windows && Teredo Tunneling
Pseudo-Interface" from this test.

Please let me know if you have any comments or suggestions.

Thank you

Tristan

/Tristan Yan(Haibo Yan)/

/Office : 8610-61066212/

/Fax : 8610-61065441/

/Cell : 86-18610696822/

//

/2F, Building No. 24, Zhongguancun Software Park/

/Haidian District Beijing
<http://people.us.oracle.com/pls/oracle/f?p=8000:6:396067987304343:::6:P6_CITY:Beijing> 


, 100193/

oracle

RFR for JDK-8022963 /java/net/NetworkInterface/Equals.java fails with java.lang.RuntimeException: equality different for net8

[Tristan Yan]

Hi Everyone I am working on bug https://bugs.openjdk.java.net/browse/JDK-8022963. Root cause for this bug is Windows API has inconsistent behavior for Teredo Tunneling Interface, based on the discussion with Chris Hegarty, we decided to fix this test with removing "Windows && Teredo Tunneling Pseudo-Interface" from this test. Please let me know if you have any comments or suggestions. Thank you Tristan  Tristan Yan(Haibo Yan)Office : 8610-61066212Fax  : 8610-61065441Cell  : 86-18610696822 2F, Building No. 24, Zhongguancun Software ParkHaidian District Beijing , 100193 

答复: Fix for https://bugs.openjdk.java.net/browse/JDK-8017779

[Tristan Yan]

Hi Chris
Have you verified Kurchi's changes, tested, reviewed
Yes, I did, I tested Kurchi's fix in one of our failed machine(sc11136394.us), 
with 1000 times run, I still can see one time failure.

Have you modified Kurchi's changes from her original review request
Yes, that's exact what I did, I stole her code and change and moved line 163, 
192, 193 and line 322. I also verify the final fix in our failed 
machine(sc11136394.us) with 1000 times run, it all passed.
Thank you very much
Tristan

-邮件原件-
发件人: Chris Hegarty 
发送时间: Tuesday, October 22, 2013 5:47 PM
收件人: Tristan Yan
抄送: net-dev@openjdk.java.net
主题: Re: Fix for https://bugs.openjdk.java.net/browse/JDK-8017779

Hi Tristan,

I agree with you, option 2 is probably better.

Have you verified Kurchi's changes, tested, reviewed, etc?
Have you modified Kurchi's changes from her original review request?

I can sponsor this change.

Thanks,
-Chris.

On 22/10/2013 07:22, Tristan Yan wrote:
> Hi Everyone
>
> I have a fix for https://bugs.openjdk.java.net/browse/JDK-8022211, 
> could you review it.
>
> Since we have Kurchi's code change out for review for re-writing this 
> test to use the new HTTP Server API. We have 2 option here 1. Just 
> fixing the bug with move setCondition around.
> 2. Adopting Kurchi's code change and my fix together as a whole fix.
> I propose we're using second way, the reason is Kruchi was using 
> modern API of JDK, it's less error-prone and make test shorter, I'd 
> like to shameless steal her fix as part of my fix.
>
> http://cr.openjdk.java.net/~pzhang/Tristan/8017779/webrev/
>
> /Tristan Yan(Haibo Yan)/
>
> /Office : 8610-61066212/
>
> /Fax : 8610-61065441/
>
> /Cell : 86-18610696822/
>
> //
>
> /2F, Building No. 24, Zhongguancun Software Park/
>
> /Haidian District Beijing
> <http://people.us.oracle.com/pls/oracle/f?p=8000:6:396067987304343:::6
> :P6_CITY:Beijing>
> , 100193/
>
> oracle
>

Fix for https://bugs.openjdk.java.net/browse/JDK-8022211

[Tristan Yan]

Hi Everyone I have a fix for https://bugs.openjdk.java.net/browse/JDK-8022211, could you review it.Since we have Kurchi's code change out for review for re-writing this test to use the new HTTP Server API. We have 2 option here 1. Just fixing the bug with move setCondition around. 2. Adopting Kurchi's code change and my fix together as a whole fix. I propose we're using second way, the reason is Kruchi was using modern API of JDK, it's less error-prone and make test shorter, I'd like to shameless steal her fix as part of my fix.  http://cr.openjdk.java.net/~pzhang/Tristan/8017779/webrev/ Tristan Yan(Haibo Yan)Office : 8610-61066212Fax  : 8610-61065441Cell  : 86-18610696822 2F, Building No. 24, Zhongguancun Software ParkHaidian District Beijing , 100193 

Fix for JDK-8023555

[Tristan Yan]

Please review fix for JDK-8023555http://cr.openjdk.java.net/~pzhang/Tristan/webrev/Thanks  Tristan Yan(Haibo Yan)Office : 8610-61066212Fax  : 8610-61065441Cell  : 86-18610696822 2F, Building No. 24, Zhongguancun Software ParkHaidian District Beijing , 100193