Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX

After a brief discussion with Chris, we decided to revert the position of the call to lookupIfLocalAddrs so as to give the local host primacy over DNS. Latest (and hopefully last) webrev here: http://cr.openjdk.java.net/~robm/7180557/webrev.03/ -Rob On 14/09/13 00:00, Rob McKenna wrote

Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX

robably you should throw JNU_ThrowOutOfMemoryError(env, "Object allocation failed"); -Dmitry On 2013-09-20 18:58, Rob McKenna wrote: After a brief discussion with Chris, we decided to revert the position of the call to lookupIfLocalAddrs so as to give the local host primacy over DNS

Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX

cking, explicit == -1 would be better here. Actually, can you tell me why you'd rather not include ipv6 loopbacks at all? If interface don't have ipv6 address but we have ipv6 loopback it most likely means that ipv6 is not functioning properly. -Dmitry On 2013-10-04 19:03, Rob McK

Re: RFR: 7180557 - InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX

Heh, you just beat me to the punch. -Rob On 07/10/13 17:34, Dmitry Samersoff wrote: Rob, Existing code uses if (JVM_GetHostName(myhostname, NI_MAXHOST)) so I withdraw my last comments. Please, don't change it!!! -Dmitry On 2013-10-07 20:30, Rob McKenna wrote: Thanks Dmitry!

hg: jdk8/tl/jdk: 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs

Changeset: f1e31376f419 Author:robm Date: 2013-10-09 00:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1e31376f419 7180557: InetAddress.getLocalHost throws UnknownHostException on java7u5 on OSX webbugs Reviewed-by: chegar, dsamersoff ! src/solaris/native/java/net/Inet4

RFR: JDK-8026245,,InetAddress.getLocalHost crash if IPv6 disabled (macosx)

Hi folks, Looking for a review for the following: http://cr.openjdk.java.net/~robm/8026245/webrev.01/ It seems there were a number of issues with the original fix for 7180557. This patch resolves those: - No existing net tests exercised the ipv4 only codepath - the extern to lookupIfLocalhos

Re: RFR: JDK-8026245, , InetAddress.getLocalHost crash if IPv6 disabled (macosx)

Caught me. I've just updated the tests in place actually. Another jprt job is in progress. (I've just checked preferIPv4 manually and it passes) I'll add a new webrev with your other suggestions. -Rob On 15/10/13 15:23, Alan Bateman wrote: On 15/10/2013 15:05, Rob McK

Re: RFR: JDK-8026245, , InetAddress.getLocalHost crash if IPv6 disabled (macosx)

Updated webrev at: http://cr.openjdk.java.net/~robm/8026245/webrev.02/ -Rob On 15/10/13 15:31, Rob McKenna wrote: Caught me. I've just updated the tests in place actually. Another jprt job is in progress. (I've just checked preferIPv4 manually and it passes) I'll add a

hg: jdk8/tl/jdk: 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx)

Changeset: d8eec0e3a023 Author:robm Date: 2013-10-16 15:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d8eec0e3a023 8026245: InetAddress.getLocalHost crash if IPv6 disabled (macosx) Reviewed-by: chegar, alanb ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/

hg: jdk8/tl/jdk: 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds

Changeset: 8d1d5a5aeb41 Author:robm Date: 2013-10-18 16:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d1d5a5aeb41 8024660: TEST_BUG: java/lang/ProcessBuilder/*IOHandle.java leaving hotspot.log open in fastdebug builds Reviewed-by: alanb Contributed-by: pavel.pune...@ora

RFR: 8005068 - HttpCookie does not correctly handle negative maxAge values

Hi folks, Simple enough change here. As per the description HttpCookie.setMaxAge will set any arbitrary negative value, while we only check for MAX_AGE_UNSPECIFIED to determine whether a cookies max age has been specified or not. This fix sets maxAge to MAX_AGE_UNSPECIFIED if the setMaxAge(ex

Re: RFR: 8005068 - HttpCookie does not correctly handle negative maxAge values

only P1-3 bugs are being accepted [1]. I see this is a P4. Should it be deferred to the next available minor update, or do you think it warrants being fixed in jdk8. -Chris. [1] http://openjdk.java.net/projects/jdk8/milestones#Rampdown_start On 18/10/2013 18:36, Rob McKenna wrote: Hi

hg: jdk8/tl/jdk: 8024521: (process) Async close issues with Process InputStream

Changeset: e2ec05b2ed94 Author:igerasim Date: 2013-10-23 15:37 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e2ec05b2ed94 8024521: (process) Async close issues with Process InputStream Reviewed-by: psandoz, martin, alanb, robm ! src/solaris/classes/java/lang/UNIXProcess.jav

hg: jdk8/tl/jdk: 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java

Changeset: 63b696dafc8a Author:robm Date: 2013-11-19 15:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/63b696dafc8a 8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java Reviewed-by: chegar, alanb ! test/java/lang/ProcessBuilder/Basic.java

hg: jdk8/tl/jdk: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug

Changeset: 89fccc5a7469 Author:martin Date: 2013-11-21 16:06 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89fccc5a7469 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java

hg: jdk8/tl/jdk: 8029525: java/lang/ProcessBuilder/Basic.java fails intermittently

Changeset: 72ea199e3e1b Author:robm Date: 2013-12-05 16:19 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/72ea199e3e1b 8029525: java/lang/ProcessBuilder/Basic.java fails intermittently Reviewed-by: alanb, chegar Contributed-by: roger.ri...@oracle.com ! test/java/lang/Process

hg: jdk8/tl/jdk: 7152892: some jtreg tests fail with permission denied

Changeset: da4b0962ad11 Author:robm Date: 2014-02-10 14:35 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da4b0962ad11 7152892: some jtreg tests fail with permission denied Reviewed-by: coffeys ! test/java/lang/ClassLoader/Assert.sh ! test/java/rmi/registry/readTest/readTest

RFR: 8031435: Ftp download does not work properly for ftp user without password

Hi folks, Very simple fix to allow FtpURLConnection connect without a password in the url. (i.e. ftp://user@server/ as opposed to the current ftp://user:@server) http://cr.openjdk.java.net/~robm/8031435/webrev.01/ -Rob

RFR: 8067680: (sctp) Possible race initializing native IDs

This is a fix to a possible race in the current sctp code. In a nutshell the conditional only checks that isaCls is not null. However if isaCls is set by one thread and that thread is interrupted before setting isaCtrID, the interrupting thread will falsely assume that isaCtrID has been set.

RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Solaris only

Hi folks, Mistakenly neglected to exclude Solaris from testing: http://cr.openjdk.java.net/~robm/8075039/webrev.01/ -Rob

Re: RFR: 8075039: (sctp) com/sun/nio/sctp/SctpMultiChannel/SendFailed.java fails on Solaris only

Pressed send a little too early. This test was added by: 8067846: (sctp) InternalError when receiving SendFailedNotification http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b10dc4dc6903 -Rob On 18/03/15 23:27, Rob McKenna wrote: Hi folks, Mistakenly neglected to exclude Solaris from testing

RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection

Hi folks, Looking for a review of this webrev: http://cr.openjdk.java.net/~robm/8077155/webrev.01/ Basically the subjects credentials are not available to HttpURLConnection.getInputStream0 since it now runs in a doPrivileged block. Changing that to doPrivilegedWithCombiner allows getInputStre

Re: RFR: 8077155: LoginContext Subject ignored by jdk8 sun.net.www.protocol.http.HttpURLConnection

the same change. Michael On 20/05/15 13:24, Rob McKenna wrote: Hi folks, Looking for a review of this webrev: http://cr.openjdk.java.net/~robm/8077155/webrev.01/ Basically the subjects credentials are not available to HttpURLConnection.getInputStream0 since it now runs in a doPrivileged block

Re: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses

Hi Brian, By coincidence I just started looking at this today myself. We have an existing bug filed for this issue: https://bugs.openjdk.java.net/browse/JDK-8080819 The diagnosis looks good. -Rob On 22/05/15 07:56, Brian Toal wrote: The fix for https://bugs.openjdk.java.net/browse/

Re: 8080819: [PATCH] fix Inet4AddressImpl.lookupAllHostAddr returning unroutable addresses

Adding bug id to subject for reference. -Rob On 22/05/15 16:05, Rob McKenna wrote: Hi Brian, By coincidence I just started looking at this today myself. We have an existing bug filed for this issue: https://bugs.openjdk.java.net/browse/JDK-8080819 The diagnosis looks good

RFR: 8080819: Inet4AddressImpl regression caused by JDK-7180557

Hi folks, 7180557 used getifaddrs as a way of determining the local hosts ip address on Mac OSX in order to fix a problem with OSX's naming system. When fixing this we decided to place that call before the call to getaddrinfo thus taking the naming system out of the equation. Unfortunately w

Re: RFR: 8080819: Inet4AddressImpl regression caused by JDK-7180557

Thanks Michael, A test would be pretty tricky given the configuration specific nature of the problem. (Mac, VPN etc.) -Rob On 03/06/15 16:22, Michael McMahon wrote: Seems reasonable Rob. I guess a test isn't feasible? Michael. On 03/06/15 14:25, Rob McKenna wrote: Hi

RFR: 8133015 - InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6

Hi folks, Upon investigating what turned out to be a network traffic filtering problem it was noticed that Windows InetAddress.isReachable() leverages TCP to detect other hosts on the network. Since new APIs for using ICMP have been implemented in Windows 2000 it could be helpful to support th

RFR - 8087190: Regression in sun.net.util.IPAddressUtil.isIPv4LiteralAddress(String)

Hi folks, looking for a review for this simple change. The change for https://bugs.openjdk.java.net/browse/JDK-8040747 initialised each octet to 0. This meant that ... was translated to 0.0.0.0 before checking the validity of the address. This small change remedies that. http://cr.openjdk.ja

Re: RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified

Please ignore the formatting errors. Thats either a problem with hg diff or webrev, but its fixed in the repo. -Rob On 24/09/15 15:43, Rob McKenna wrote: Hi folks, The recent change to isReachable (8133015: InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6

RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified

Hi folks, The recent change to isReachable (8133015: InetAddress.isReachable(tmout) returning wrong value on Windows for IPv6 - http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/59ff6cd9535d) neglected to take the specified interface into account for ipv4. This change ensures that isReachable ret

Re: RFR: 8135305: InetAddress.isReachable reports true when loopback interface is specified

? regards Mark On 24/09/2015 15:45, Rob McKenna wrote: Please ignore the formatting errors. Thats either a problem with hg diff or webrev, but its fixed in the repo. -Rob On 24/09/15 15:43, Rob McKenna wrote: Hi folks, The recent change to isReachable (8133015: InetAddress.isReachable(t

Re: Request for review & approval: 8141260: isReachable crash in windows xp

forgot to cc net-dev -Rob On 24/11/15 16:37, Rob McKenna wrote: Hi folks, The recently updated ICMP (8133015) code fails on Windows XP due to a missing api. This fix allows XP to fall back to the old tcp based method: https://bugs.openjdk.java.net/browse/JDK-8141260 http

Re: Request for review & approval: 8141260: isReachable crash in windows xp

wxp_ping4(env, this, addrArray, timeout, ifArray, ttl) } regards Mark On 25/11/2015 15:32, Seán Coffey wrote: Looks ok to me Rob and provides a re-introduction of the old Java_java_net_Inet4AddressImpl_isReachable0 function for XP systems where necessary. Reviewed. Approved for

8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

It appears that there is an undocumented minimum timeout in the IcmpSendEcho* functions. If the timeout parameter is set to a number below this minimum timeout it is effectively ignored. Thus if you wanted to ensure that you could ping a particular host within a certain timeout less than the un

Re: 8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

than the specified timeout in any case: http://cr.openjdk.java.net/~robm/8143397/webrev.02/ -Rob On 01/12/15 14:59, Rob McKenna wrote: It appears that there is an undocumented minimum timeout in the IcmpSendEcho* functions. If the timeout parameter is set to a number below this minimum timeo

Re: 8143397: It looks like InetAddress.isReachable(timeout) works incorrectly

that it is not reliable if the timeout is too small? At least 1000ms timeout by default may be not acceptable in some circumstances. Xuelei On 12/9/2015 12:31 AM, Rob McKenna wrote: Testing has shown that when a timeout < 1000ms is specified the IcmpSendEcho calls fail (apparently) randomly. O

8150234: Windows 10 App Containers disallow access to ICMP calls

Hi folks, Looking for a review for this change. Basically https://bugs.openjdk.java.net/browse/JDK-8135305 abandoned the old TCP echo isReachable check in favour of Windows' ICMP calls on supported platforms. Unfortunately it turns out that Windows 10's new App Containers don't actually allow

RFR: 6947916: JarURLConnection does not handle useCaches correctly

Hi folks, Looking for a review of this simple enough fix: http://cr.openjdk.java.net/~robm/6947916/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-6947916 In a nutshell, if multiple URLConnections are made to several files in a single jar, each will use the same backing JarFile object. Unfo

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

.java.net/~robm/6947916/webrev.02/ -Rob On 08/09/16 08:40, Chris Hegarty wrote: > > > On 7 Sep 2016, at 14:17, Rob McKenna wrote: > > > > Hi folks, > > > > Looking for a review of this simple enough fix: > > > > http://cr.openjdk.java.ne

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

Will do -Rob On 09/09/16 11:00, Roger Riggs wrote: > Hi Rob, > > Looks ok. > > Its also a good practice to cleanup the file. (File.deleteOnExit). > > Roger > > > On 9/9/2016 9:23 AM, Rob McKenna wrote: > >Hey Chris, > > > >Apologies,

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

Chris just pointed out to me that the test.classes prefix on the jar path is unnecessary. He also mentioned that jtreg would clear up the scratch directory so the deleteOnExit wouldn't be needed either. -Rob On 09/09/16 05:02, Rob McKenna wrote: > Will do > > -Rob

Re: RFR: 6947916: JarURLConnection does not handle useCaches correctly

To be explicit, new webrev here: http://cr.openjdk.java.net/~robm/6947916/webrev.03/ -Rob On 09/09/16 07:03, Rob McKenna wrote: > Chris just pointed out to me that the test.classes prefix on the jar path is > unnecessary. He also mentioned that jtreg would clear up the s

RFR - 8165988: Test JarURLConnectionUseCaches.java fails at windows: failed to clean up files after test

Hi folks, A resource cleanup issue can cause this test to fail on windows, fix is to run in othervm: http://cr.openjdk.java.net/~robm/8165988/webrev.01/ -Rob

RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

Hi folks, I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* calls can actually return a similar set of errors regardless of whether the call itself failed or succeeded. This change checks that both the call and the ping were successful. In addition to that it takes a nu

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

> Mark > > regards > Mark > On 21/09/2016 16:16, Rob McKenna wrote: > >Hi folks, > > > >I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* > >calls can actually return a similar set of errors regardless of whether the &g

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

, Vyom > > > On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: > >Hi folks, > > > >I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* > >calls can actually return a similar set of errors regardless of whether the > >call

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

lse if the underline API > IcmpSendEcho return with Status== IP_SUCESS and RoundTripTime > timeout. > > Vyom > > > On Wednesday 21 September 2016 10:39 PM, Rob McKenna wrote: > >Unfortunately the behaviour described is undocumented and was found the hard > >way.

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

is. I think in case of IP_SUCCESS > >>"RoundTripTime" is always less than timeout. I think similar changes is > >>required in Inet6Address.c as well ? Thanks, Vyom > >> > >>On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: > >>>Hi

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

The link would be handy: http://cr.openjdk.java.net/~robm/8159410/webrev.02/ -Rob On 21/09/16 07:44, Rob McKenna wrote: > I've updated the webrev here with the copyright year (thanks Christoph) and > extra error codes. I overlooked the codes from the old implementation of

Re: RFR - 8159410: InetAddress.isReachable returns true for non existing IP addresses

g has been > > missed, should it occur. > > So at the risk of triggering another MS curiosity, the changes look fine > > +1 > > -Chris. > > > regards > > Mark > > > > On 21/09/2016 19:45, Rob McKenna wrote: > >> The link would be han

RFR - 8166747: Add invalid network / computer name cases to isReachable known failure switch

Hi folks, Looking for a review of this simple addition to Inet4AddressImpl.c on Windows. As per the bug report: In the ping4() call in Inet4AddressImpl.c on Windows there is a switch statement containing failure codes for IcmpSendEcho which correspond to well known and expected failures for th

[RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Hi folks, In high latency environments a client SSLSocket with autoClose set to false can hang indefinitely if it does not correctly recieve a close_notify from the server. In order to rectify this situation I would like to suggest that we implement an integer JDK property (jdk.tls.closeRetries)

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

grant > to be gracefully. > > What do you think? > > BTW, please file a CSR as this update is introducing an external system > property. > > Thanks, > Xuelei > > On 9/11/2017 3:29 PM, Rob McKenna wrote: > >Hi folks, > > > >In high latency envi

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

gt;slow, surely there will be other issues with connecting and reading, why is > >closing any different. > > > >-Chris. > > > >>On 13 Sep 2017, at 16:52, Rob McKenna wrote: > >> > >>Hi Xuelei, > >> > >>This behaviour is already exposed

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 9/13/2017 8:52 AM, Rob McKenna wrote: > >W.r.t. a separate timeout, the underlying mechanics of a close already > >depend on the readTimeout in this situation. > That's a concerns of mine. In order to work for your countermeasure, > applications have to set receiving tim

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 13/09/17 03:52, Xuelei Fan wrote: > > > On 9/13/2017 8:52 AM, Rob McKenna wrote: > >Hi Xuelei, > > > >This behaviour is already exposed via the autoclose boolean in: > > > >https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLSocketFa

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 15/09/17 07:07, Xuelei Fan wrote: > On 9/15/2017 7:00 AM, Rob McKenna wrote: > >When we call close() on the SSLSocket that calls close() on the > >underlying java Socket which closes the native socket. > > > Sorry, I did not get the point. Please see the close() imple

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

tely) -Rob On 15/09/17 07:23, Xuelei Fan wrote: > On 9/15/2017 7:07 AM, Rob McKenna wrote: > >But they are inextricably linked regardless. > > > >When we close an SSLSocket it performs a readReply which is subject to > >the read timeout. So if no read timeout is spe

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 15/09/17 07:32, Xuelei Fan wrote: > On 9/15/2017 7:16 AM, Rob McKenna wrote: > >On 13/09/17 03:52, Xuelei Fan wrote: > >> > >> > >>On 9/13/2017 8:52 AM, Rob McKenna wrote: > >>>Hi Xuelei, > >>> > >>>This beh

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

Xuelei Fan wrote: > On 9/15/2017 7:44 AM, Rob McKenna wrote: > >Perhaps I'm misunderstanding you here. Can you illustrate this a bit > >further? > > > The basic point is simple: removing the closing blocking even receiving > timeout is not set. > > >Applicat

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

On 15/09/17 07:55, Xuelei Fan wrote: > On 9/15/2017 7:41 AM, Rob McKenna wrote: > >On 15/09/17 07:07, Xuelei Fan wrote: > >>On 9/15/2017 7:00 AM, Rob McKenna wrote: > >>>When we call close() on the SSLSocket that calls close() on the > >>>underlying java So

Re: [RFR] 8184328: JDK8u131 socketRead0 hang at SSL read

/2017 4:32 PM, Xuelei Fan wrote: > >On 9/15/2017 8:22 AM, Rob McKenna wrote: > >>This test calls close directly. (3rd last line in the stack) > >> > >>I believe this is the only possible stack (with the new parameter) once > >>autoclose is set to

Re: upgrade to jdk6 com.sun.httpserver

W.r.t. alternatives the HTTP serving landscape on the JVM is rich and diverse at this point. Projects worth a look include Grizzly, Netty, Jetty, Tomcat, Undertow, Rapidoid and the many cool frameworks build on top of these technologies. (e.g. Jooby, SparkJava, Play to name a few) -Rob On 20

[RFR] 8219640: UnresolvedAddressException not thrown for incorrect hostname

Hi folks, Assuming the premise of this bug is correct, could I get a review for the following: https://bugs.openjdk.java.net/browse/JDK-8219640 http://cr.openjdk.java.net/~robm/8219640/webrev.01/ Windows rejects a lookup for "127.0.0.1 test" where getaddrinfo on non-Windows platforms resolves to

Re: [RFR] 8219640: UnresolvedAddressException not thrown for incorrect hostname

Thanks for the pointer to the passing host Alan. With that I was able to track down: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=108bc4049f8ae82710aec26a92ffdb4b439c83fd So it looks like this has recently been fixed in glibc. -Rob On 03/09/19 17:47, Alan Bateman wrote: > On 03/09

RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found

Hi folks, If a FileNotFoundException is thrown when attempting to load a class from a jar file, a reference to the open JarFile remains even after the loader is closed. The test in the webrev demonstrates the problem by attempting to delete the JarFile after attempting a class load. The deletion

RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found

isky. > > I see that your test caters for all possible setting of uses cache > and combination of success/failure when opening the jar entry, > so this give me confidence that the fix is working as intended. > > best regards, > > -- daniel > > > On 24/11/2019 15

Re: RFR: 8132359 - JarURLConnection.getJarFile() resource leak when file is not found

ns explored that fixed it in the protocol handler instead. > > -Alan > > On 25/11/2019 13:31, Rob McKenna wrote: > > Thanks Daniel, > > > > cc'ing core-libs-dev in case there are any objections. > > > > -Rob > > > > On 25/11/19 10:47, Da

hg: jdk7/tl/corba: 2 new changesets

Changeset: f642c9ec81a0 Author:robm Date: 2010-11-15 10:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/f642c9ec81a0 6277781: Serialization of Enums over IIOP is broke. Summary: Reviewed by Ken Cavanaugh Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/io/I

hg: jdk8/tl/jdk: 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close

Changeset: b700f85a8f29 Author:robm Date: 2012-04-17 07:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b700f85a8f29 7118373: (se) Potential leak file descriptor when deregistrating at around the same time as an async close Reviewed-by: alanb ! src/share/classes/sun/nio/c

RFR: 7166687: InetAddress.getLocalHost().getHostName() returns FQDN

Hi folks, A typo in the MacOSX work led to a regression in b11 of 7u4. Specifically: http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/diff/5cca2f1a37da/src/solaris/native/java/net/Inet6AddressImpl.c As per the bug report the && in the 2nd #if macro meant that this condition was ignored and the solar

hg: jdk8/tl/jdk: 7166687: InetAddress.getLocalHost().getHostName() returns FQDN

Changeset: b26c04717735 Author:robm Date: 2012-05-07 13:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b26c04717735 7166687: InetAddress.getLocalHost().getHostName() returns FQDN Reviewed-by: chegar ! src/solaris/native/java/net/Inet6AddressImpl.c

hg: jdk8/tl/jdk: 7168110: Misleading jstack error message

Changeset: 178c480998b1 Author:robm Date: 2012-05-17 22:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/178c480998b1 7168110: Misleading jstack error message Reviewed-by: alanb, dsamersoff ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c

hg: jdk8/tl/jdk: 7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with preferIPv6Addresses=true

Changeset: a7895dc61088 Author:robm Date: 2012-06-08 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7895dc61088 7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with preferIPv6Addresses=true Reviewed-by: alanb, chegar ! src/share/classes/sun/

hg: jdk8/tl/jdk: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

Changeset: ff0da4ea08a2 Author:robm Date: 2012-06-26 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff0da4ea08a2 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Reviewed-by: alanb ! src/share/classes/java/lang/Process.java ! src/solaris/class

hg: jdk8/tl/jdk: 7174887: Deadlock in jndi ldap connection cleanup

Changeset: ecc5dd3790a1 Author:robm Date: 2012-07-02 19:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ecc5dd3790a1 7174887: Deadlock in jndi ldap connection cleanup Reviewed-by: xuelei ! src/share/classes/com/sun/jndi/ldap/Connection.java ! src/share/classes/com/sun/jndi

hg: jdk8/tl/jdk: 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled

Changeset: 516e0c884af2 Author:robm Date: 2012-07-09 22:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/516e0c884af2 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled Reviewed-by: dholmes, chegar ! src/solaris/classes/sun/nio/fs/LinuxU

hg: jdk8/tl/jdk: 6931128: (spec) File attribute tests fail when run as root.

Changeset: da14e2c90bcb Author:robm Date: 2012-08-15 22:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/da14e2c90bcb 6931128: (spec) File attribute tests fail when run as root. Reviewed-by: alanb ! src/share/classes/java/io/File.java ! test/java/io/File/Basic.java ! test/j

hg: jdk8/tl/jdk: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896

Changeset: 59aa7660ade4 Author:robm Date: 2012-08-20 14:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59aa7660ade4 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896 Reviewed-by: dholmes, alanb ! test/java/lang/ProcessB

request for review: 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache

Hi folks, Looking for a review for: 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache http://cr.openjdk.java.net/~robm/7199219/webrev.01/ Basically we never set the correct Tunn

RFR: 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases

Hi folks, This one is connected to 7199219 and has an intersecting change in that we're similarly passing the httpuc from HttpURLConnection. Despite the intersection I've filed these as two separate issues because a) they are and b) I wouldn't like one to be held up by the other. The problem

hg: jdk8/tl/jdk: 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases

Changeset: 11a5da68673c Author:robm Date: 2012-09-27 22:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11a5da68673c 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases Reviewed-by: chegar ! src/share/classes/sun/net/www

hg: jdk8/tl/jdk: 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache

Changeset: b3c7a3138c5d Author:robm Date: 2012-09-28 04:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3c7a3138c5d 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache Reviewed-by: chegar ! src/share/classes/sun/net/

RFR: 7199862 & 7199219 - jdk7u

Hi folks, Lumping these backports together. 7199219: Proxy-Connection headers set incorrectly when a HttpClient is retrieved from the Keep Alive Cache 7199862: Make sure that a connection is still alive when retrieved from KeepAliveCache in certain cases Webrevs at: http://cr.openjdk.java.ne

hg: jdk8/tl/jdk: 7184932: Remove the temporary Selector usage in the NIO socket adapters

Changeset: bba370caafad Author:robm Date: 2012-10-04 19:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bba370caafad 7184932: Remove the temporary Selector usage in the NIO socket adapters Reviewed-by: alanb ! make/java/nio/mapfile-bsd ! make/java/nio/mapfile-linux ! make/

hg: jdk8/tl/jdk: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

Changeset: 7c2f5e52863c Author:robm Date: 2012-10-11 18:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7c2f5e52863c 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol] Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Bas

hg: jdk8/tl/jdk: 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout

Changeset: c0736b62160e Author:robm Date: 2012-10-15 22:34 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c0736b62160e 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/Connection.

request for review: 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests

Hi folks, Looking to move a pair of tests into the open repo: http://cr.openjdk.java.net/~robm/8003597/webrev.01/ Thanks, -Rob

hg: jdk8/tl/jdk: 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests

Changeset: 40311b5f478f Author:robm Date: 2012-11-28 00:47 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

Shouldn't 'cal.set(1970, 0, 1, 0, 0, 0)' be inside the for loop? The test can simply throw Exception, rather can catching. Otherwise, looks fine to me. -Crhis. On 06/12/2012 21:19, Rob McKenna wrote: Hi folks, According to HttpCookie.java: """ There are 3 http cookie

Re: Request for review: 8000525: Java.net.httpcookie api does not support 2-digit year format

..the url would be helpful: http://cr.openjdk.java.net/~robm/8000525/webrev.02/ -Rob On 12/12/12 15:43, Rob McKenna wrote: Hi Chris, I guess I figured if the parse failed the cal.set wouldn't happen. Still, no harm in moving the 1970 into the loop on the off chance something else

hg: jdk8/tl/jdk: 8004337: java/sql tests aren't run in test/Makefile

Changeset: 68374c6e65c1 Author:robm Date: 2012-12-12 15:57 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68374c6e65c1 8004337: java/sql tests aren't run in test/Makefile Reviewed-by: lancea, alanb ! test/Makefile

hg: jdk8/tl/jdk: 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently

Changeset: 44d6cabc9a3f Author:robm Date: 2013-01-15 19:58 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java

RFR: 8009251 - Add proxy handling and keep-alive fixes to jsse

Hi folks, I'd like to port some changes around proxy handling, keep alive and tunnelling to the HttpsClient. These should have been done along with the HttpClient. Webrev is at: http://cr.openjdk.java.net/~robm/8009251/webrev.01/ related issues: https://jbs.oracle.com/bugs/browse/JDK-719921

Re: OpenJDK HTTP Client Bug

garty" To: "Stuart Douglas" Cc: "Alessio Soldano" , "OpenJDK Network Dev list" , "Rob McKenna" Sent: Saturday, 2 March, 2013 7:37:30 PM Subject: Re: OpenJDK HTTP Client Bug [bcc'ing off jdk7-...@openjdk.java.net, and including net-dev@openjdk.java.net]

Re: OpenJDK HTTP Client Bug

ssage saying it was awaiting moderator approval as I am not a member). Stuart Rob McKenna wrote: Thanks for this Stuart, do you happen to have a reference to the bug you filed on the Oracle site? -Rob On 02/03/13 08:55, Stuart Douglas wrote: Seeing as the patch appears to have been stripped

Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed

Hi folks, This is a slight alteration of the fix contributed by Stuart Douglas. This fix deals with a SocketException caused by getSoTimeout() on a closed connection. http://cr.openjdk.java.net/~robm/8009650/webrev.01/ -Rob

Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed

The outer try/catch is meant to catch potential exceptions originating from the inner try/finally. (from setSoTimeout) -Rob On 07/03/13 16:51, Kurchi Subhra Hazra wrote: I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna wrote: Hi folks

Re: Request for review: 8009650 - HttpClient available() check throws SocketException when connection has been closed

I've fleshed out the bug report a little to make that clearer, sorry Kurchi! Also, I'll add a testcase to this review soon. -Rob On 07/03/13 16:51, Kurchi Subhra Hazra wrote: I am wondering why do you need two try-catch blocks here. - Kurchi On 3/7/13 8:18 AM, Rob McKenna

  1   2   >