hg: jdk8/tl/jdk: 8029348: ProblemList.txt updates (11/2013)
Changeset: 5bcaf730ceb8 Author:tyan Date: 2013-11-29 09:29 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bcaf730ceb8 8029348: ProblemList.txt updates (11/2013) Reviewed-by: chegar ! test/ProblemList.txt
RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
should have been this list by rights!! regards Mark Original Message Subject: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java Date: Fri, 29 Nov 2013 14:21:33 + From: Mark Sheppard Organization: Oracle Corporation To: core-libs-dev Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machines. this replaces a Thread.sleep(5000) with explicit synchronization between sender and receiver via a CountDownLatch regards Mark
Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machines. this replaces a Thread.sleep(5000) with explicit synchronization between sender and receiver via a CountDownLatch (cc'ing net-dev) Would an alternative here be to just get rid of the server thread (do both the send + receive on the main thread)? -Alan
Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
On 11/29/13 5:19 PM, Alan Bateman wrote: On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machines. this replaces a Thread.sleep(5000) with explicit synchronization between sender and receiver via a CountDownLatch (cc'ing net-dev) Would an alternative here be to just get rid of the server thread (do both the send + receive on the main thread)? Hmm... The message sent by the server is short enough so that it should be stored in the client's socket buffer and received later by the client, even though the client is not yet blocked waiting in clientSock.receive() when the message is sent. That might work. Unless multi-threading was relevant to the configuration being tested? -- daniel -Alan
RFR: 8029354: URLPermission. throws llegalArgumentException: Invalid characters in hostname
Hi, java.net.URLPermission does not currently take account of the "userinfo" component in the authority of a URL. So, it does not accept URLs of the form "http://username@host/blah"; http://cr.openjdk.java.net/~michaelm/8029354/webrev.1/ which includes a small spec change to account for this. Userinfo needs to be case-sensitive for comparison, hashCode() etc. Thanks, Michael
Re: RFR: JDK-8025211 - Intermittent test failure: java/net/DatagramSocket/PortUnreachable.java
Alan, Daniel, thanks for the replies. yes, 'tis a possibility, and it appears to work ok as a test, as it avoids the sender's Thread.sleep creating a race condition, such that the send doesn't happen prior to the timeout of the client receive. The context of the test appears to be creating conditions such that an ICMP PortUnreachable event is generated, which caused a close a particular version of windows. The test is for socket closed scenario, afaik tested on the errant test machine with consistent success. regards Mark On 29/11/2013 16:41, Daniel Fuchs wrote: On 11/29/13 5:19 PM, Alan Bateman wrote: On 29/11/2013 14:21, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025211/webrev/ which address the issue raised in the bug https://bugs.openjdk.java.net/browse/JDK-8025211 an intermittent failure occurs on some windows test machines. this replaces a Thread.sleep(5000) with explicit synchronization between sender and receiver via a CountDownLatch (cc'ing net-dev) Would an alternative here be to just get rid of the server thread (do both the send + receive on the main thread)? Hmm... The message sent by the server is short enough so that it should be stored in the client's socket buffer and received later by the client, even though the client is not yet blocked waiting in clientSock.receive() when the message is sent. That might work. Unless multi-threading was relevant to the configuration being tested? -- daniel -Alan
RFR: 8029127: A redirect POST request does not work and illegalStateException on HttpURLConnection.getInputStream
This is another regression in JDK 8. A new "connecting" flag is getting confused when a redirect occurs and a POST gets converted to a GET. http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/ Thanks Michael.
Re: RFR: 8029127: A redirect POST request does not work and illegalStateException on HttpURLConnection.getInputStream
On 29/11/2013 18:03, Michael McMahon wrote: This is another regression in JDK 8. A new "connecting" flag is getting confused when a redirect occurs and a POST gets converted to a GET. http://cr.openjdk.java.net/~michaelm/8029127/webrev.1/ The change looks okay but I do have a few comments on the test. Copyright dates make it look like it came from 2006 :-) Is the @compile tag right, shouldn't it compile RedirectOnPost too? Might be easier to use /com/sun/... as / indicates the root of the test tree. Import of javax.xml.soap, I can't see this being used. Does the test really need to use SSL? I guess I don't like seeing tests need to grab files from other locations in the test tree. Is "error" used? Should the statics be moved into main? runTest (L72-74), looks like the formatting is messed up here. runTest - would be nice if this used try-with-resources. Otherwise I think the test seems to cover the redirect okay, it just needs a bit of polishing so that it can be maintained. -Alan.
