Code Review 6934054: java/net/Socket/FDClose.java return error in samevm
Hi Alan, Michael, Another small test change! This test requires interruptible I/O to verify that the accept implementation does not impact on fd0. UseVMInterruptibleIO needs to be explicitly enabled since it is now disabled by default, see 6554406. Without interruptible I/O the thread executing the accept gets blocked and the test harness cannot perform the necessary cleanup required by samevm. Note: This test is only applicable to Solaris, since it is the only platform to support interruptible I/O, but should still pass on all platforms. Webrev: http://cr.openjdk.java.net/~chegar/6934054/webrev.00/webrev/ Thanks, -Chris.
Re: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm
Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Alan, Michael, Another small test change! This test requires interruptible I/O to verify that the accept implementation does not impact on fd0. UseVMInterruptibleIO needs to be explicitly enabled since it is now disabled by default, see 6554406. Without interruptible I/O the thread executing the accept gets blocked and the test harness cannot perform the necessary cleanup required by samevm. Note: This test is only applicable to Solaris, since it is the only platform to support interruptible I/O, but should still pass on all platforms. Webrev: http://cr.openjdk.java.net/~chegar/6934054/webrev.00/webrev/ Thanks, -Chris. I'm tempted to suggest that the best thing is to just hg rm the test as it's not very useful. If you want to keep it then the changes looks OK to me. One suggestion is to have AReader implement Closeable and have the close implement just do sock.close(). -Alan.
Re: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm
Alan Bateman wrote: . I'm tempted to suggest that the best thing is to just hg rm the test as it's not very useful. If you want to keep it then the changes looks OK This had crossed my mind. If you agree then I think I will just remove it. -Chris. to me. One suggestion is to have AReader implement Closeable and have the close implement just do sock.close(). -Alan.
Re: Code Review 6934054: java/net/Socket/FDClose.java return error in samevm
Christopher Hegarty -Sun Microsystems Ireland wrote: Alan Bateman wrote: . I'm tempted to suggest that the best thing is to just hg rm the test as it's not very useful. If you want to keep it then the changes looks OK This had crossed my mind. If you agree then I think I will just remove it. The bazooka would be a fine choice.
hg: jdk7/tl/jdk: 6934054: java/net/Socket/FDClose.java return error in samevm
Changeset: 07e1c5a90c6a Author:chegar Date: 2010-03-11 16:17 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07e1c5a90c6a 6934054: java/net/Socket/FDClose.java return error in samevm Summary: test is no longer useful Reviewed-by: alanb ! test/ProblemList.txt - test/java/net/Socket/FDClose.java
Re: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy
Christopher Hegarty -Sun Microsystems Ireland wrote: Hi All, This patch fixes a problem where the socks proxy implementation does not honor the timeout specified in Socket.connect(SocketAddress, timeout). In fact, it uses the read timeout set with setSoTimeout since the socks implementation opens a connection to the socks server to perform the socks protocol. This also violates the spec since a timeout of 0 means block indefinitely. It is worth noting that the proposed fix changes the current behavior as specified above; SO_TIMEOUT no longer impacts on the timeout when using a socks proxy. Do you mean there that SO_TIMEOUT does not affect the connect behavior, but it still works when reading off the socket after it is connected? Thanks Michael
Re: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy
Michael McMahon wrote: Christopher Hegarty -Sun Microsystems Ireland wrote: Hi All, This patch fixes a problem where the socks proxy implementation does not honor the timeout specified in Socket.connect(SocketAddress, timeout). In fact, it uses the read timeout set with setSoTimeout since the socks implementation opens a connection to the socks server to perform the socks protocol. This also violates the spec since a timeout of 0 means block indefinitely. It is worth noting that the proposed fix changes the current behavior as specified above; SO_TIMEOUT no longer impacts on the timeout when using a socks proxy. Do you mean there that SO_TIMEOUT does not affect the connect behavior, but it still works when reading off the socket after it is connected? Yes, this is correct. Since we need to read off the socket during the connection process to implement the socks protocol, the SO_TIMEOUT (before this fix) had an impact on the connection timeout. After this change SO_TIMEOUT will only impact on SocketInputStream reads, connection timeout can be implemented through the Socket.connect API. -Chris. Thanks Michael
Re: Code Review: 6223635 Code hangs at connect call even when Timeout is specified when using a socks proxy
Christopher Hegarty -Sun Microsystems Ireland wrote: Michael McMahon wrote: Christopher Hegarty -Sun Microsystems Ireland wrote: Hi All, This patch fixes a problem where the socks proxy implementation does not honor the timeout specified in Socket.connect(SocketAddress, timeout). In fact, it uses the read timeout set with setSoTimeout since the socks implementation opens a connection to the socks server to perform the socks protocol. This also violates the spec since a timeout of 0 means block indefinitely. It is worth noting that the proposed fix changes the current behavior as specified above; SO_TIMEOUT no longer impacts on the timeout when using a socks proxy. Do you mean there that SO_TIMEOUT does not affect the connect behavior, but it still works when reading off the socket after it is connected? Yes, this is correct. Since we need to read off the socket during the connection process to implement the socks protocol, the SO_TIMEOUT (before this fix) had an impact on the connection timeout. After this change SO_TIMEOUT will only impact on SocketInputStream reads, connection timeout can be implemented through the Socket.connect API. Ok, just checking that. The fix looks fine to me then. - Michael
hg: jdk7/tl/jdk: 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode
Changeset: c342735a3e58 Author:chegar Date: 2010-03-11 17:37 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c342735a3e58 6933629: java/net/HttpURLConnection/HttpResponseCode.java fails if run in samevm mode Reviewed-by: alanb ! test/ProblemList.txt ! test/java/net/CookieHandler/CookieHandlerTest.java
hg: jdk7/tl/jdk: 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy
Changeset: c6f8c58ed51a Author:chegar Date: 2010-03-11 17:50 + URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c6f8c58ed51a 6223635: Code hangs at connect call even when Timeout is specified when using a socks proxy Reviewed-by: michaelm, chegar Contributed-by: damjan@gmail.com ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java + test/java/net/Socket/SocksConnectTimeout.java
hg: jdk7/tl/jdk: 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile
Changeset: ee385b4e2ffb Author:sherman Date: 2010-03-11 14:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee385b4e2ffb 6929479: Add a system property sun.zip.disableMemoryMapping to disable mmap use in ZipFile Summary: system property sun.zip.disableMemoryMapping to disable mmap use Reviewed-by: alanb ! src/share/classes/java/util/zip/ZipFile.java ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h
