Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. In agentvm mode, multiple threads may share the thread pool. SunJSSE implementation initialize the SSL/TLS context at the first time the context get loaded, and will not dynamically change the context anymore after the initialization. If a test case has initialized the context, another test case share the same thread will use the same context. New settings in the later will have no impact on the context. The cause of the bug is that some other test case updated the context, and CookieHttpsClientTest cannot setup the context as expected. Need to make the test case run in othervm mode. Thanks, Xuelei
Re: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
On 23/01/2012 12:21, Xuelei Fan wrote: Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. In agentvm mode, multiple threads may share the thread pool. SunJSSE implementation initialize the SSL/TLS context at the first time the context get loaded, and will not dynamically change the context anymore after the initialization. If a test case has initialized the context, another test case share the same thread will use the same context. New settings in the later will have no impact on the context. The cause of the bug is that some other test case updated the context, and CookieHttpsClientTest cannot setup the context as expected. Need to make the test case run in othervm mode. Thanks, Xuelei This looks fine to me, thanks for jumping on this annoying test failure. -Alan. PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in error.
Re: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
Remove the serviceabilty-dev. Thanks for the quick code review. Xuelei On 1/23/2012 8:25 PM, Alan Bateman wrote: On 23/01/2012 12:21, Xuelei Fan wrote: Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. In agentvm mode, multiple threads may share the thread pool. SunJSSE implementation initialize the SSL/TLS context at the first time the context get loaded, and will not dynamically change the context anymore after the initialization. If a test case has initialized the context, another test case share the same thread will use the same context. New settings in the later will have no impact on the context. The cause of the bug is that some other test case updated the context, and CookieHttpsClientTest cannot setup the context as expected. Need to make the test case run in othervm mode. Thanks, Xuelei This looks fine to me, thanks for jumping on this annoying test failure. -Alan. PS: cc'ing security-dev as I'm guessing you cc'ed serviceabilty-dev in error.
hg: jdk8/tl/jdk: 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
Changeset: d383b5d128e3 Author:xuelei Date: 2012-01-23 04:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d383b5d128e3 7132248: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java
Re: Code review request [JDK 8]: 7132248, sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHttpsClientTest.java failing
Thanks for taking care of this Andrew. -Chris. On 23/01/2012 12:21, Xuelei Fan wrote: Webrev: http://cr.openjdk.java.net/~xuelei/7132248/webrev.00/ In JDK 8, the regression tests of JSSE (HTTP/TLS) run in agentvm mode. In agentvm mode, multiple threads may share the thread pool. SunJSSE implementation initialize the SSL/TLS context at the first time the context get loaded, and will not dynamically change the context anymore after the initialization. If a test case has initialized the context, another test case share the same thread will use the same context. New settings in the later will have no impact on the context. The cause of the bug is that some other test case updated the context, and CookieHttpsClientTest cannot setup the context as expected. Need to make the test case run in othervm mode. Thanks, Xuelei
RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx]
Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ The problem is that poll(2) doesn't seem to work in a specific edge case tested by JCK, namely, when a zero length UDP message is sent on a DatagramSocket. The problem is only detected on timed reads, ie. normal blocking reads work fine. The fix is to make the NET_Timeout() function use select() instead of poll(). Thanks, Michael.
Re: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx]
On 23/01/12 17:09, Michael McMahon wrote: Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ The problem is that poll(2) doesn't seem to work in a specific edge case tested by JCK, namely, when a zero length UDP message is sent on a DatagramSocket. The problem is only detected on timed reads, ie. normal blocking reads work fine. The fix is to make the NET_Timeout() function use select() instead of poll(). Thanks, Michael. Forgot to mention, that the second file in the webrev is a file that needs to be removed from the repo, and which was added unintentionally in a previous merge. Thanks, Michael.
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 3df0bd3ed880 Author:mullan Date: 2012-01-23 12:17 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3df0bd3ed880 7131084: XMLDSig XPathFilter2Transform regression involving intersect filter Reviewed-by: xuelei ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! test/javax/xml/crypto/dsig/KeySelectors.java ! test/javax/xml/crypto/dsig/ValidationTests.java ! test/javax/xml/crypto/dsig/X509KeySelector.java + test/javax/xml/crypto/dsig/data/xmldsig-xfilter2.xml Changeset: 5e1ad6ad41b7 Author:mullan Date: 2012-01-23 13:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e1ad6ad41b7 Merge
hg: jdk8/tl/jdk: 7132338: Use @code friendly idiom for '\' in javadoc
Changeset: 91471160 Author:darcy Date: 2012-01-23 12:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91471160 7132338: Use @code friendly idiom for '\' in javadoc Reviewed-by: alanb ! src/share/classes/java/io/DataInput.java ! src/share/classes/java/io/LineNumberInputStream.java ! src/share/classes/java/io/RandomAccessFile.java ! src/share/classes/java/io/StreamTokenizer.java ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/util/Properties.java
Re: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx]
On 23/01/2012 17:09, Michael McMahon wrote: Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ The problem is that poll(2) doesn't seem to work in a specific edge case tested by JCK, namely, when a zero length UDP message is sent on a DatagramSocket. The problem is only detected on timed reads, ie. normal blocking reads work fine. The fix is to make the NET_Timeout() function use select() instead of poll(). Thanks, Michael. The first argument to select is s+1, shouldn't is be 1? -alan
Re: RFR: 7131399: Poll system call appears to be broken on Mac OS [macosx]
On 23/01/12 21:30, Alan Bateman wrote: On 23/01/2012 17:09, Michael McMahon wrote: Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/7131399/webrev.1/ The problem is that poll(2) doesn't seem to work in a specific edge case tested by JCK, namely, when a zero length UDP message is sent on a DatagramSocket. The problem is only detected on timed reads, ie. normal blocking reads work fine. The fix is to make the NET_Timeout() function use select() instead of poll(). Thanks, Michael. The first argument to select is s+1, shouldn't is be 1? -alan No, I don't think so. fd_sets are bit masks and you have to specify the highest numbered bit in the mask (+1). - Michael.
