Hi Xuelei,
Thanks for your comment very much!
I was resolving the race condition issue on a closed JDK test, which
depends on javax/net/ssl/sanity/interop/CipherTest.java.
Such tests have the similar code patterns. I supposed the open JDK
tests, javax/net/ssl/sanity/interop/CipherTest.java,
sun/security/pkcs11/fips/CipherTest.java and
sun/security/pkcs11/sslecc/CipherTest.java, have the same race
condition issue.
But, in fact, the scenario in the closed JDK test is different from the
open JDK ones.
I'll close this issue.
Best regards,
John Jiang
On 2016/6/7 9:44, Xuelei Fan wrote:
Hi John,
If I understand correctly, you have the client side wait for a while so
that the server can get run. This update may mitigate the race
condition, but cannot get rid of the race condition. After the timeout,
the server may still not ready.
Did you catch a testing failure of the race condition? I was wondering
after the server socket is created, it would be ready to accept client
connections even the server thread does not call socket.accept() yet.
It may be not necessary to have client wait for server thread ready in
this context. A testing failure of the race condition would be helpful
for further evaluation.
Thanks,
Xuelei
On 6/7/2016 6:43 AM, John Jiang wrote:
Hi,
Please review this patch. Thanks!
John Jiang
On 2016/6/2 20:54, John Jiang wrote:
Hi,
Please review this updated webrev:
http://cr.openjdk.java.net/~jjiang/8158462/webrev.01
I just updated the year in copyright notice.
Best regards,
John Jiang
On 2016/6/2 14:11, John Jiang wrote:
Hi,
Please review this patch on resolving possible race condition for the
following tests:
javax/net/ssl/sanity/interop/CipherTest.java
sun/security/pkcs11/fips/CipherTest.java
sun/security/pkcs11/sslecc/CipherTest.java
Webrev: http://cr.openjdk.java.net/~jjiang/8158462/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8158462
Best regards,
John Jiang
