CFV: Project sponsorship: SCTP

roup are eligible to vote on this decision. The current Members are: Alan Bateman Christopher Hegarty Michael McMahon Jean-Christophe Collet Thanks, Michael [1] http://mail.openjdk.java.net/pipermail/net-dev/2008-October/000427.html

Re: CFV: Project sponsorship: SCTP

Vote: yes

Re: CFV: Project sponsorship: SCTP

Regarding the CFV on the following question[1]: Should the Networking Group sponsor the "SCTP" Project? Voting has now concluded. I have received "Yes" votes from the following 4 members of the Core Libraries Group: Christopher Hegarty Alan Bateman Jean-Christophe Col

Re: MulticastSocket(group, port) problems with bind() with IPv6 enabled

Alan Bateman wrote: Pekka Savola wrote: Hi, I've looked through the Sun bug database and AFAICS this is not listed. I've also looked through the latest source code to see if this is addressed [1], but apparently not. I'm trying to find a way to get this addressed. When you create a Multi

Re: Request for Review: 6775145

Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Michael, Jessie, Please take a few moments to review this trivial change: http://cr.openjdk.java.net/~chegar/6775145/webrev.00/webrev/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6775145 6775145: ClassLoaderUtil.releaseLo

Re: HttpServer - issue in handling of "Expect: 100-continue"

Hi Stewart, My reading of RFC2616 on this question suggests that the server isn't wrong sending a Content-Length: 0 header with the initial 100-Continue response, regardless of whether or not, the final response will contain a chunked response body. The 100- Continue is a normal response, struct

Re: [security-dev 00429]: Request for comment: How to enable credentials delegation in HTTP Negotiate?

Max, One question. Would this mechanism work for any possible GSS security mechanism? In other words, is all the information you need encapsulated inside a single GSSCredential object? Also, java.net.Authenticator was designed very much for the original HTTP authentication schemes (Basic and

Re: Review request for 4890703

Alan Bateman wrote: Michael - can you review this? It's the updates to support SDP on Solaris. The webrev is here: http://cr.openjdk.java.net/~alanb/4890703/webrev.00/ Thanks, Alan. Consider it reviewed. - Michael.

Re: FW: setTrafficClass on server socket; IP_TOS replacement on Windows

Alan Bateman wrote: setTrafficClass on a server socket, so that a certain TOS value will be present in the ACK packet when TCP accepts a connection. This would occur automatically because all socket flags are inherited during construction of the native socket on the backlog queue, then Java tu

Re: Request for Review 6855335

Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Michael, Jessie, I need a code review for some SCTP changes that were found during testing. CR 6855335: Several changes in the SCTP implementation. Webrev: http://cr.openjdk.java.net/~chegar/6855335/webrev.00/webrev/ 1) SctpMultiC

Re: Request for Review 6855335

Christopher Hegarty - Sun Microsystems Ireland wrote: On 29/06/2009 11:32, Michael McMahon wrote: Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Michael, Jessie, I need a code review for some SCTP changes that were found during testing. CR 6855335: Several changes in the SCTP

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 806c5e4d1265 Author:michaelm Date: 2009-06-29 13:10 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/806c5e4d1265 6513803: httpserver regression test Test13 failing and causing NullPointerException Summary: check for NPEs Reviewed-by: chegar ! test/com/sun/net/http

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 89b14d3740dc Author:michaelm Date: 2009-06-29 15:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89b14d3740dc 6827999: 6827999: URLClassLoader.addURL(URL) adds URLs to closed class loader Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/

Re: Request for Review 6882654

Looks fine to me. Thanks, Michael. Christopher Hegarty - Sun Microsystems Ireland wrote: 6882654: Remove dependency on java.util.concurrent from KeepAlive implementaion Webrev: http://cr.openjdk.java.net/~chegar/6882654/webrev.0/webrev/ The HTTP keep alive implementation has unnecessary

Review for 6886108

Can I get the following test case change reviewed? http://cr.openjdk.java.net/~michaelm/6886108/webrev.01/ The problem is a test case binding to a fixed port number which fails randomly, if the port is in use. The test needs to reuse the same port number itself, but it just remembers the one tha

hg: jdk7/tl/jdk: 2 new changesets

Changeset: dd724911c90a Author:michaelm Date: 2009-09-29 10:00 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd724911c90a 6886108: Test case B4933582 binding to fixed port number Reviewed-by: chegar ! test/java/net/Authenticator/B4933582.java ! test/sun/net/www/httptest/Htt

Code review 6870935

Hello, Can I get the following code change reviewed please. http://cr.openjdk.java.net/~michaelm/6870935/webrev.01/ - Michael.

Re: Code review 6870935

fine. -Chris. P.S. Good to see we're getting new tests for this this code :-) Michael McMahon wrote: Hello, Can I get the following code change reviewed please. http://cr.openjdk.java.net/~michaelm/6870935/webrev.01/ - Michael.

hg: jdk7/tl/jdk: 2 new changesets

Changeset: f0fdc4dd97d5 Author:michaelm Date: 2009-10-02 13:57 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0fdc4dd97d5 6870935: DIGEST proxy authentication fails to connect to URLs with no trailing slash Reviewed-by: chegar ! src/share/classes/sun/net/www/protocol/http/

review 6886436

Can I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/6886436/webrev.03/ Thanks, Michael.

hg: jdk7/tl/jdk: 2 new changesets

Changeset: 57fe28f3878a Author:michaelm Date: 2009-10-15 12:03 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/57fe28f3878a 6886436: Lightwight HTTP Container (com.sun.* package) is unstable Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/sh

hg: jdk7/tl/jdk: 6890349: Fix #6870935 in jdk7/pit/b74 caused HttpClinet's check for "proxy capture" attack by-passed.

Changeset: 052f056f7ba1 Author:michaelm Date: 2009-10-20 15:35 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/052f056f7ba1 6890349: Fix #6870935 in jdk7/pit/b74 caused HttpClinet's check for "proxy capture" attack by-passed. Summary: pass exception up stack Reviewed-by: cheg

Re: Request for Review: 6893238

Christopher Hegarty - Sun Microsystems Ireland wrote: CR 6893238: Move NTLM and SPNEGO implementations into separate packages Webrev: http://cr.openjdk.java.net/~chegar/6893238/webrev.0/webrev/ Following 688259, NTLM and SPNEGO authentication implementations are now runtime dependencies. The

Re: Request for Review: 6909089

Alan Bateman wrote: Christopher Hegarty -Sun Microsystems Ireland wrote: CR 6909089: Memory leak occurs by lack of free for read buffer in SocketInputStream#read() Webrev: http://cr.openjdk.java.net/~chegar/6909089/webrev.0/webrev/ Bug description says it all. -Chris. Looks okay to me -

Re: Virtual Host support on the embedded HTTP server

Hi David, Apologies for missing this when it was suggested originally. Is there a particular use case you have in mind that requires the generality provided by the HostMatcher interface? (as opposed to the simpler name based approach as Chris said) Presumably, with HostMatcher, you would have

Re: Virtual Host support on the embedded HTTP server

David M. Lloyd wrote: Responses inline. On 12/14/2009 12:20 PM, Michael McMahon wrote: Hi David, Apologies for missing this when it was suggested originally. Is there a particular use case you have in mind that requires the generality provided by the HostMatcher interface? (as opposed to the

Re: Some questions on IIS on Windows 2008

Max (Weijun) Wang wrote: Hi All I've just installed a Windows 2008 system with IIS, and find something confusing: 1. What does "Enable Kernel-mode authentication" mean? When it's turned on, I can successfully authenticate using NTLM. When it's off, the three NTLM packets looks fine, but the

Re: new URI("http://example.com/foo#bar").resolve("")

I don't think this is a bug. Everything to the right of the final "/" in the original URI is discarded when resolving against any relative URI. So, "foo#bar" is correctly discarded, leaving the new URI http://example.com/ That would be my reading of RFC2396 anyway. - Michael. Jack Bates wrote

Re: Request for Review: 6707289

Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Micahel, Jessie, 6707289: InterfaceAddress.getNetworkPrefixLength() does not conform to Javadoc getAddrsFromAdapter (src/windows/native/java/net/NetworkInterface_winXP.c) makes an incorrect assumption that the list of IP_ADAPTER_PREFI

Re: new URI("http://example.com/foo#bar").resolve("")

could affect existing code. Thanks, Michael. Jack Bates wrote: Hi Michael, On Mon, 2010-01-25 at 11:20 +0000, Michael McMahon wrote: I don't think this is a bug. Everything to the right of the final "/" in the original URI is discarded when resolving against any relative URI.

Re: new URI("http://example.com/foo#bar").resolve("")

Jack, 6920138 is the reference for this bug. Thanks, Michael. Jack Bates wrote: Hi Michael, On Mon, 2010-01-25 at 11:20 +, Michael McMahon wrote: I don't think this is a bug. Everything to the right of the final "/" in the original URI is discarded when resolving again

Re: Request for Review: 6693244

Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Michael, This is a forward port to JDK7. The very same fix is already in 6u10, 5.0uXX and 1.4.2_XX. There is the possibility that endAuthRequest can be invoked twice with the same key. endAuthRequest in turn invokes requestCompleted, wh

Re: 6365587: Proxy-Connection header sent through tunnel

Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Michael, I need a review for CR 6365587: "Proxy-Connection header sent through tunnel". Proxy-Connection header is being sent to the http server over an SSL tunnel. The Proxy-Connection header is only of interest to the proxy. You can

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 o

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

Re: Code Review 6935199: java/net regression tests failing with Assertions

Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Michael, The following tests have incorrect assertion failures if run with assertions enabled: test/java/net/CookieHandler/TestHttpCookie.java Would it be better to just remove the assertion in the first one as well? test/java/net/

Re: Code Review 6935199: java/net regression tests failing with Assertions

Christopher Hegarty -Sun Microsystems Ireland wrote: Michael McMahon wrote: Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Michael, The following tests have incorrect assertion failures if run with assertions enabled: test/java/net/CookieHandler/TestHttpCookie.java Would it be

Re: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String

Christopher Hegarty - Sun Microsystems Ireland wrote: On 19/03/2010 14:42, Alan Bateman wrote: Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Michael, This is a forward port of a fix that you did in JDK6u11 to JDK7. The source changes are trivial and the very same as what went in 6.

Re: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String

Christopher Hegarty - Sun Microsystems Ireland wrote: On 19/03/2010 15:04, Michael McMahon wrote: Christopher Hegarty - Sun Microsystems Ireland wrote: On 19/03/2010 14:42, Alan Bateman wrote: Christopher Hegarty - Sun Microsystems Ireland wrote: Hi Michael, This is a forward port of a fix

Re: Code Review 6706251: api/java_net/NetworkInterface/index.html#misc: getDisplayName() returned non null but empty String

Looks good to me. - Michael. Christopher Hegarty - Sun Microsystems Ireland wrote: How about (thanks to Alan for the wording): * A display name is a human readable String describing the network * device. * - * @return the display name of this network interface, - *

Re: Code Review 6648001: Cancelling HTTP authentication causes subsequent deadlocks

Christopher Hegarty -Sun Microsystems Ireland wrote: Hi Michael, This is a forward port of a fix that you put in 6uXX. By exposing the key used in the authentication cache outside of AuthenticationInfo, this allows all requests to be terminated correctly, including ones, that have no username

Re: Request for Review 6886723: light weight http server doesn't return correct status code for HEAD requests

Forwarding to list --- Begin Message --- Looks good. Only comment would be that maybe the test should (also) exercise the more common "HEAD" scenario where an explicit Content-length is set. Since the test runs a number of times, maybe the handler could alternate between chunked and fixed lengt

Re: Request for Review 6886723: light weight http server doesn't return correct status code for HEAD requests

Chris Hegarty wrote: On 05/05/2010 11:22, Michael McMahon wrote: Looks good. Only comment would be that maybe the test should (also) exercise the more common "HEAD" scenario where an explicit Content-length is set. Since the test runs a number of times, maybe the handler could alterna

Re: Request for Review 6886723: light weight http server doesn't return correct status code for HEAD requests

Looks good. Only comment would be that maybe the test should (also) exercise the more common "HEAD" scenario where an explicit Content-length is set. Since the test runs a number of times, maybe the handler could alternate between chunked and fixed length. - Michael. Chris Hegarty wrote: Mic

Re: Code Review Request 6946825: com.sun.net.httpserver.HttpServer; Memory Leak on Non HTTP conform open socket

Looks fine. - Michael. Chris Hegarty wrote: Hi Michael, The Server implementation keeps a list of HttpConnection instances (which hold SelektionKeyImpl instances) per connection. After accepting a new connection a HttpConnection is created and added to the list. It is never removed if the r

Re: Code Review 6947917: Error in basic authentication when user name and password are long

Looks fine. - Michael. Chris Hegarty wrote: Michael, A minor change to the encoder used for Basic Authentication. Webrev: http://cr.openjdk.java.net/~chegar/6947917/webrev.00/webrev/ The Basic Authentication implementation, sun.net.www.protocol.http.BasicAuthentication, uses a sun.misc.B

Code review 6773270: java.net.URI fails to escape \u0000

Alan, Could you review this small change, when you get a chance please? http://cr.openjdk.java.net/~michaelm/6773270/webrev.1/ Thanks, Michael.

Re: Request to review fix in IPv6 JTreg tests (java/net/ipv6tests/)

Hi Pavel, From what I can see this code is invoked from the method getFirstLocalIPv6Address() which would expect to get a link local address, but the nature of the new test is to reject link local addressses. Thanks, Michael. Pavel Tisnovsky wrote: Hi, could you please review the small change

Re: Code Review 6954525: java/net/BindException/Test.java 6 tests(s) failed - see log

Chris Hegarty wrote: Michael, java/net/BindException/Test.java and java/net/ipv6tests/Tests.java have code that iterator over the network interfaces looking for IPv4 addresses to test with. In some cases, it is possible to have an interface that is up with an IPv4 address of 0.0.0.0. This is

Re: Code Review 6966846: Incorrect assertion in java.net.Inet6Address.readObject

Chris Hegarty wrote: Michael, CR 6966846: Incorrect assertion in java.net.Inet6Address.readObject The readObject implementation tries to determine the scope_id of the network interface, given its name ( if there is one ). It in correctly asserts that the interface must have at least one IPv6

Re: Code Review 6967684: httpserver using a non thread-safe SimpleDateFormat

Chris Hegarty wrote: Michael, CR 6967684: httpserver using a non thread-safe SimpleDateFormat Bug description says it all. I guess in reality this may have gone unseen for so long because, if two or more threads were servicing requests the dates they would be generating should be fairly simil

Re: Code Review 6967684: httpserver using a non thread-safe SimpleDateFormat

Chris Hegarty wrote: On 07/09/10 10:10, Michael McMahon wrote: Chris Hegarty wrote: Michael, CR 6967684: httpserver using a non thread-safe SimpleDateFormat Bug description says it all. I guess in reality this may have gone unseen for so long because, if two or more threads were servicing

Re: Code Review 6967684: httpserver using a non thread-safe SimpleDateFormat

Chris Hegarty wrote: On 07/09/10 11:27, Michael McMahon wrote: Chris Hegarty wrote: On 07/09/10 10:10, Michael McMahon wrote: Chris Hegarty wrote: Michael, CR 6967684: httpserver using a non thread-safe SimpleDateFormat Bug description says it all. I guess in reality this may have gone

Re: Code Review 6967684: httpserver using a non thread-safe SimpleDateFormat

Chris Hegarty wrote: On 07/09/10 12:10, Michael McMahon wrote: Chris Hegarty wrote: On 07/09/10 11:27, Michael McMahon wrote: Chris Hegarty wrote: On 07/09/10 10:10, Michael McMahon wrote: Chris Hegarty wrote: Michael, CR 6967684: httpserver using a non thread-safe SimpleDateFormat

Code review 6510892: com/sun/net/httpserver/bugs/B6361557.java fails

Chris, Could you review this one please. Test opens 1000 sockets, which is close to the default limit on many Linuxes. Solution is to run in othervm mode. http://cr.openjdk.java.net/~michaelm/6510892/webrev.1/ Thanks Michael.

Re: Code review 6510892: com/sun/net/httpserver/bugs/B6361557.java fails

Michael McMahon wrote: Chris, Could you review this one please. Test opens 1000 sockets, which is close to the default limit on many Linuxes. Solution is to run in othervm mode. http://cr.openjdk.java.net/~michaelm/6510892/webrev.1/ Thanks Michael. updated webrev at http

Re: Code Review 6973030: NTLM proxy authentication fails with https

Chris Hegarty wrote: Michael, Send the "Proxy-Connection: keep-alive" header with HTTP CONNECT requests for compatibility with HTTP/1.0 proxies such as Squid. This is required for NTLM authentication. Webrev: http://cr.openjdk.java.net/~chegar/6973030/webrev.00/webrev/ Thanks, -Chris. Lo

Re: Code Review 6973030: NTLM proxy authentication fails with https

Chris Hegarty wrote: On 07/30/10 14:44, Michael McMahon wrote: Chris Hegarty wrote: Michael, Send the "Proxy-Connection: keep-alive" header with HTTP CONNECT requests for compatibility with HTTP/1.0 proxies such as Squid. This is required for NTLM authentication. We

Code review: 6339649

Chris, Could you review the following small change? http://cr.openjdk.java.net/~michaelm/6339649/webrev.1/ I think it's a useful change, since many applications won't bother to even catch the runtime exception except at a fairly generic high level and it is useful (in this case) to have the mes

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

gustav trede wrote: On 18 August 2010 12:10, Chris Hegarty > wrote: Michael, java.net.HttpCookie uses static SimpleDateFormat which is not thread safe. I think the best solution here is to simply create local SimpleDateFormat as needed. We

Re: Code Review 6965924: java.net.HttpCookie using static SimpleDateFormat which is not thread safe

gustav trede wrote: On 19 August 2010 17:50, Chris Hegarty <mailto:chris.hega...@oracle.com>> wrote: gustav trede wrote: On 18 August 2010 13:22, Michael McMahon mailto:michael.x.mcma...@oracle.com> <mailto:michael.x.mcm

Re: Code Review 6977851: NPE from FileURLConnection.connect

Chris Hegarty wrote: Michael, The file handler can fail with NPE in cases where permission is denied to the directory. Small change, throw FileNotFoundException where a directory listing is not available. Webrev: http://cr.openjdk.java.net/~chegar/6977851/webrev.00/webrev/ Thanks, -Chris.

Re: code review request: 6911951: NTLM should be a supported Java SASL mechanism

Why is the serialVersionUid changed in NTLMAuthentication? Otherwise, the encapsulation of NTLM in the new API looks quite concise and neat to me? Looks fine. - Michael Vincent Ryan wrote: The SASL component looks good Max. Michael/Chris: have you any comments on the NTLM changes? On 25/0

Re: code review request: 6911951: NTLM should be a supported Java SASL mechanism

Weijun Wang wrote: The internal structure of NTLMAuthentication is changed and that's why I changed the serialVersionUid as well. If unchanged, I guess the old serialized form can still be accepted by the new class, but all new field will become null/0. After the change, any such deserializatio

Re: Small improvements to Inet6 implementation (unix)

Martin Buchholz wrote: Hi net maintainers, I'd like you to do a code review. I got frustrated with incomplete information from exceptions thrown from java.net , so I hacked up some fixes for them. This is the result. generify; remove compiler warnings, typos, casts; return

Re: Small improvements to Inet6 implementation (unix)

Alan Bateman wrote: Martin Buchholz wrote: I just noticed that I get gai_strerror_ptr dynamically, but then called gai_strerror directly and incorrectly. Here's a more robust way to get the error string: const char *error_string = (gai_strerror_ptr == NULL) ? NULL : (*gai_strerror

Re: 6965072: update SDP support

Alan Bateman wrote: Michael - do you mind reviewing this one? This is a change to the SDP support to make it easy to provide an API in the future. For now it includes a simple implementation specific API. The existing transparent support continues to work but is reorganized to allow for bot

Review 6550798

Chris, Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/6550798/webrev.1/ Thanks, Michael.

Re: Code Review 6987461: Handle leak when enabling java.net.useSystemProxies

Chris Hegarty wrote: Michael, There is a leak in the windows version of the default proxy selector implementation. If no proxy is enabled on the system, i.e. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable = 0, then the handle to the registry key is n

Re: 6989190: SO_SNDBUF/SO_RCVBUF limits should only be checked when setsockopt fails (sol)

Looks fine. Thanks, Michael. Alan Bateman wrote: I need a reviewer for a small change to the networking code. On Solaris, the SO_SNDBUF/SO_RCVBUF parameters are clamped by the values of the tcp_max_buf and udp_max_buf parameters. Unfortunately the code in net_util_md.c has been using a priv

Re: Code Review 6993490: SocketTimeoutException on HTTP keep-alive connections

Chris Hegarty wrote: Hi Michael, The resetting of the read timeout after, error stream buffering, Expect 100-Continue handling, and keepalive cleaner, may be problematic if the read timeout is the default value. The default read tmeout is -1 ( not set ), but Networkclient.setReadTimeout ignor

Re: Code Review 7004439: SCTP_SET_PEER_PRIMARY_ADDR throws SocketException on Linux

Chris Hegarty wrote: Hi Michael, The native sockaddr is not being correctly set in sctp_setpeerprim. Also, the value of SCTP_SET_PEER_PRIMARY_ADDR should not be an IPv4-mapped address for IPv4 addresses on lksctp. It should be an IPv4 address, in a similar way to how we handle addresses being

Re: Code Review 7010903: impl. of http.maxConnections is different from the description in JavaSE document

Chris Hegarty wrote: Michael, Trivially, the number of keep-alive connections is not being correctly compared to the maximum number, set by http.maxConnections. The condition is "greater than" and allows the cache keep a number of http.maxConnections + 1. hg diff src/share/classes/sun/net/w

Re: Code Review 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi

Chris Hegarty wrote: Michael, Alan, There is an issue in InetAddress.getAddressesFromNameService, whereby if the nameservice provider throws an unchecked exception it leaves the host being looked up in the lookupTable. This will cause any further lookups of that host to block and wait forever

Re: Code Review 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi

Alan Bateman wrote: Chris Hegarty wrote: On 01/20/11 04:33 PM, Alan Bateman wrote: ... One small suggestion is to rename B6442088.java while you are there (it looks odd given that the rest of the tests have proper names). All tests now have "real" names, and I updated the @build to @compile

Re: Code Review 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache

Chris Hegarty wrote: Alan, Michael, Trivially, set the thread context classloader to null for the keep-alive timer and cache cleaner threads. http://cr.openjdk.java.net/~chegar/7008595/webrev.00/webrev/ Thanks, -Chris. Seems reasonable. - Michael.

Re: Code Review 7022269: clean up fscanf usage in soalris networking native code

Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http://cr.openjdk.java.net/~chegar/7022269/webrev.00/webrev/ -Chris.

Re: Code Review 7022269: clean up fscanf usage in soalris networking native code

Chris Hegarty wrote: On 02/25/11 02:39 PM, Michael McMahon wrote: Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large enough to handle the specified width and the null terminator. http

Re: Code Review 7022269: clean up fscanf usage in soalris networking native code

Chris Hegarty wrote: On 02/25/11 05:22 PM, Michael McMahon wrote: Chris Hegarty wrote: On 02/25/11 02:39 PM, Michael McMahon wrote: Alan Bateman wrote: Chris Hegarty wrote: Michael, Alan, Some small cleanups to the use of scanf with specified string width. The buffers should be sized large

Re: Code Review 7024560: InetAddress.getLocalHost().getHostName() returns localhost for hostnames of length HOST_NAME_MAX

Chris Hegarty wrote: Alan, Michael, In Java_java_net_Inet(4|6)AddressImpl_getLocalHostName JVM_GetHostName, a.k.a gethostname, is returning ENAMETOOLONG. Then falling back to use "localhost", the assumption was that failure would only happen when something went wrong, maybe networking is not

Re: Code Review 7030649: URL.equals() fails to compare jar urls

Chris Hegarty wrote: Alan, Michael, This is an old issue. JAR URLs may not compare equal when their enclosing URL's are. The reason is that URLStreamHandle.equals(URL,URL) and sameFile(URL,URL) doesn't know about the composite URL syntax used by JAR URLs. To resolve this we should overridden

Re: Why does the new File(URI) constructor restricts the uri to hierarchical?

Paulo, URI's with a scheme (such as file:) cannot be relative. That's a feature of the specification of URIs themselves. So, this behavior is a side-effect of the requirement that the URI provided to the constructor has a file: scheme. - Michael. On 14/05/11 18:24, Paulo Levi wrote: I have a

Re: SocketPermission's implies() interesting behavior

Looks fine, - Michael. On 18/07/11 13:25, Chris Hegarty wrote: Michael, Can you please review this change. It has already been discussed and agreed, I just rebased it against jdk8 and added a test. http://cr.openjdk.java.net/~chegar/7021280/webrev.02/webrev/ Thanks, -Chris. On 07/13/11 04

Re: Code Review 7068416: Lightweight HTTP Server should support TCP_NODELAY

Looks fine. Thanks, Michael. On 20/07/11 11:10, Chris Hegarty wrote: Hi Michael, It has been noticed that there is a perceived delay in response from the Lightweight HTTP Server implementation that ships with the JDK, compared to other production HTTP Servers. The cause for this delay has b

Re: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause

There seems to be only a couple of places where IOException (specifically) is thrown in the networking code and it can't occur in this code path as far as I can see. Perhaps that wasn't always the case, which could explain why the unusual construction exists. So, the simplification suggested be

Re: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause

On 22/07/11 13:51, Chris Hegarty wrote: On 7/22/2011 3:45 AM, Alan Bateman wrote: Kurchi Hazra wrote: Hi, Due to a recent update in javac to issue a warning on detecting unreachable code, the following warning started showing up in the jdk networking code: ../../../src/share/classes/java/net

Re: Code Review Request: 7035556 DatagramSocket.java:183: warning: unreachable catch clause

On 22/07/11 14:55, Alan Bateman wrote: Michael McMahon wrote: But, bind() already closes the impl internally before throwing the exception. I was wondering about that and whether this is a bug. Suppose someone creates an unbound DatagramSocket and then attempts to bind it to a port. If the

Re: Code Review 6670868: StackOverFlow with bad authenticated Proxy tunnels

On 26/07/11 16:21, Chris Hegarty wrote: Michael, There is an issue in the tunneling/Http retry code whereby a proxy requiring authentication, if it gives a bad response after the initial 407, may cause the HTTPClient to perform recursive calls to parseHTTP until StackOverFlow. The reason is o

Re: Socket InputStream.available may return a positive value after shutdown

On 11/08/11 17:27, Alan Bateman wrote: Chris Hegarty wrote: Here is a first stab at fixing this issue. http://cr.openjdk.java.net/~chegar/7014860/webrev.00/webrev/ -Chris. The spec clarification seems reasonable to me. Small typo "the streams available method" to "the stream's available met

Re: Code Review 7025938: Add bitmap mime type to content-types.properties

Looks fine. - Michael. On 18/08/11 17:44, Chris Hegarty wrote: Can I get a review for this contribution? It adds bitmap mime type support to content-types.properties, so that URLConnection.getContentType() returns 'image/bmp' rather than 'content/unknown'. This is not a commonly used API, bu

Re: Crash problem in net.dll

Jonathan, I think the change looks reasonable. But, we should make the equivalent change at the other site where enumAddresses_win() is called in the same file. - Michael. On 29/08/11 09:14, Jonathan Lu wrote: Hello everybody, I got one crash issue on OpenJDK7 windows build. I captured the

Re: Crash problem in net.dll

re thorough check is needed for all modules. Regards! - Jonathan Lu On 08/29/2011 04:40 PM, Michael McMahon wrote: Jonathan, I think the change looks reasonable. But, we should make the equivalent change at the other site where enumAddresses_win() is called in the same file. - Michael. On 29/08/

Re: Crash problem in net.dll

Just to be clear, I will run the tests on the fix and push the change assuming everything is ok. There is a webrev here http://cr.openjdk.java.net/~michaelm/7084560/webrev.1/ Thanks, Michael. On 29/08/11 15:33, Michael McMahon wrote: Jonathan, Bug id 7084560 has been created to track this

Re: Code Review 7041800: URI.equals may incorrectly return true with escaped octets

On 01/09/11 09:36, Chris Hegarty wrote: An embarrassing bug in the equal(String,String) private implementation method. The Strings compare equal when there is a % in one string, a different char in the same place in the other string, but the two chars following are the same. http://cr.openj

Re: Datagram socket leak

Thomas, Thanks for pointing this out. We overlooked this in the recent change in this area. One thing though, in the second change to DatagramSocket we can't just check for isBound() since the socket might legitimately be unbound (bindaddr is null). All I can think is that we catch the excepti

Re: Datagram socket leak

p after runtime exceptions. The SocketImpl finalizer does eventually clean up. But, I agree we shouldn't rely on that especially in cases like the IAE explicitly thrown in the constructor. We'll include those cases in the fix for this bug as well. Michael. -Original Message--

Re: Crash problem in net.dll

Jonathan, The tests were fine amd the fix was pushed last week. Michael. On 07/09/11 09:14, Jonathan Lu wrote: Hi Michael, Any news about the testing results of this patch? Thanks Jonathan On 08/29/2011 11:02 PM, Michael McMahon wrote: Just to be clear, I will run the tests on the fix and

Re: Datagram socket leak

chael. On 01/09/11 18:33, Michael McMahon wrote: Right. That would work assuming createImpl() doesn't leave the socket open if it throws an exception, which seems to be the case. On 01/09/11 18:05, Salter, Thomas A wrote: Maybe I posted a bad patch, but my intent was to do the try-fina

Re: Datagram socket leak

On 07/09/11 21:54, chris hegarty wrote: On 07/09/2011 17:24, Michael McMahon wrote: Hi all, I've posted a webrev for this at: http://cr.openjdk.java.net/~michaelm/7085981/webrev.1/ After checking Socket and ServerSocket, I believe they are not actually affected by this issue

Re: Datagram socket leak

On 07/09/11 21:54, chris hegarty wrote: On 07/09/2011 17:24, Michael McMahon wrote: Hi all, I've posted a webrev for this at: http://cr.openjdk.java.net/~michaelm/7085981/webrev.1/ After checking Socket and ServerSocket, I believe they are not actually affected by this issue

<    4   5   6   7   8   9   10   11   >