Re: RFR [14] 8151678: com/sun/jndi/ldap/LdapTimeoutTest.java failed due to timeout on DeadServerNoTimeoutTest is incorrect

This looks great to me. Thanks for taking a look at it. -Rob On 12/09/19 12:36, Pavel Rappo wrote: > > On 12 Sep 2019, at 03:54, Martin Buchholz wrote: > > > > We're mostly in agreement. > > Good to hear and I agree! > > > On Wed, Sep 11, 2019 at 11:02 AM Pavel Rappo >

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

RFR: JDK-8277795: ldap connection timeout not honoured under contention

This fix attemps to resolve an issue where threads can stack up on each other while waiting to get a connection from the ldap pool to an unreachable server. It does this by having each thread start a countdown prior to holding the pools' lock. (which has been changed to a ReentrantLock) Once the

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v2]

so for subsequent requests > regardless of whether an existing unused connection is available in the pool > until initSize is exhausted. As such it may require a CSR. Rob McKenna has updated the pull request incrementally with two additional commits since the last revision: - JDK-82777

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v2]

On Fri, 26 Nov 2021 10:50:57 GMT, Daniel Fuchs wrote: > What testing is there for this fix? I've just added a test modelled on LdapTimeoutTest.java. (with some whitespace issues which I'm about to fix!) > src/java.naming/share/classes/com/sun/jndi/ldap/LdapClientFactory.java line > 71: > >>

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]

so for subsequent requests > regardless of whether an existing unused connection is available in the pool > until initSize is exhausted. As such it may require a CSR. Rob McKenna has updated the pull request incrementally with one additional commit since the last revision: Allow

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]

On Thu, 13 Jan 2022 01:02:38 GMT, Mark Sheppard wrote: >> Rob McKenna has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Allow the test to pass on MacOSX > > src/java.naming/share/classes/com/sun/jndi/ldap/poo

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v4]

so for subsequent requests > regardless of whether an existing unused connection is available in the pool > until initSize is exhausted. As such it may require a CSR. Rob McKenna has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev exclu

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]

On Wed, 19 Jan 2022 15:53:57 GMT, Daniel Fuchs wrote: >> IIRC this was a request from an earlier review. (long being the standard >> throughout other new public apis) I'm happy with either, but int does avoid >> the trouble of casting. > > Well I guess the request was "why not use long everywhe

Re: RFR: JDK-8277795: ldap connection timeout not honoured under contention [v3]

On Tue, 25 Jan 2022 15:30:46 GMT, Mark Sheppard wrote: >> yes a redeclaration of timeout with a type long across the component >> would be a consistent approach, also > > so just to clarify, we're not taking the approach to homogenise the timeout > declarations, throughout the component, to

Integrated: JDK-8277795: ldap connection timeout not honoured under contention

On Thu, 25 Nov 2021 23:54:18 GMT, Rob McKenna wrote: > This fix attemps to resolve an issue where threads can stack up on each other > while waiting to get a connection from the ldap pool to an unreachable > server. It does this by having each thread start a countdown prior to holdi

RFR: 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work. - Commit messages: - 8281695: jtreg test com/sun/jndi/ldap/Ldap

Withdrawn: 8281695: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

On Fri, 27 May 2022 15:24:46 GMT, Rob McKenna wrote: > Test change to silently pass if the test environment encounters a > NoRouteToHostException. These are intermittent at the moment but I will > attempt to find an alternative to the use of example.com in some follow up > work

RFR: 8287672: jtreg test com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails intermittently in nightly run

Test change to silently pass if the test environment encounters a NoRouteToHostException. These are intermittent at the moment but I will attempt to find an alternative to the use of example.com in some follow up work. - Commit messages: - 8281695: jtreg test com/sun/jndi/ldap/Ldap

Re: Code review request: 7101658 : Backout 7082769 changes

Looks good. -Rob On 17/10/11 18:29, Alan Bateman wrote: Seán Coffey wrote: bug ID : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7101658 (bug report not visible yet) changes for 7082769 fix have led to behavioral changes which can lead to native file descriptor exhaustion. Basical

code review request : JDK 7 backport: 7102369 RedirectLimit & Redirect307Test fail intermittently

webrev : http://cr.openjdk.java.net/~robm/7095949/webrev.00/ http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7095949 -Rob

review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

Hi folks, I'm hoping for some feedback on the above. Webrev: http://cr.openjdk.java.net/~robm/4244896/webrev.00/ This bug adds two abstract methods to Process.java with the intention of: 1) providing a facility to implement a destroyForcibly method. In practical terms this means provide a met

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

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

eturn STILL_ACTIVE as an error code on their own. - Test updated to allow for proper execution of shell script. -Rob On 12/04/12 10:05, Alan Bateman wrote: On 12/04/2012 00:48, Rob McKenna wrote: Hi folks, I'm hoping for some feedback on the above. Webrev: http://cr.openjdk.java.net/~ro

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

gt; concerns raised it seems to make more sense to leave users who return > STILL_ACTIVE as an error code on their own. > - Test updated to allow for proper execution of shell script. > > -Rob > > On 12/04/12 10:05, Alan Bateman wrote: > > On 12/04/2012 00:48, Rob McKenna

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

I've uploaded another webrev to: http://cr.openjdk.java.net/~robm/4244896/webrev.02/ I plan to spend some time over the coming day or two beefing up the test for waitFor (right now its really geared towards destroyForcibly) so I won't g

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

f the change. -Rob On 20/04/12 02:53, David Holmes wrote: Hi Rob, On 20/04/2012 11:33 AM, Rob McKenna wrote: I've uploaded another webrev to: http://cr.openjdk.java.net/~robm/4244896/webrev.02/ <http://cr.openjdk.java.net/%7Erobm/4244896/webrev.02/> I'll take a look as soon a

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

notifyAll() when the process exits. -Rob On 20/04/12 17:09, Alan Bateman wrote: On 20/04/2012 02:33, Rob McKenna wrote: I've uploaded another webrev to: http://cr.openjdk.java.net/~robm/4244896/webrev.02/ <http://cr.openjdk.java.net/%7Erobm/4244896/webrev.02/> I plan to spen

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

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

Hi folks, The latest version is at: http://cr.openjdk.java.net/~robm/4244896/webrev.03/ Feedback greatly appreciated. -Rob On 19/04/12 12:05, Alan Bateman wrote: On 19/04/2012 01:05, David Holmes wrote: On 18/04/2012 11:44 PM, Ja

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

ast our timeout expiry. Would: wait(Math.max(TimeUnit.NANOSECONDS.toMillis(rem), 1)); alleviate all concerns here? -Rob Paul. On May 10, 2012, at 8:56 PM, Rob McKenna wrote: Hi folks, The latest version is at: http://cr.openjdk.java.net/~robm/4244896/webrev.03/<http://cr.openj

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

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

Latest version including work on the spec language: http://cr.openjdk.java.net/~robm/4244896/webrev.04/ <http://cr.openjdk.java.net/%7Erobm/4244896/webrev.03/> -Rob On 10/05/12 19:56, Rob McKenna wrote: Hi folks, The latest version is at: http://cr.openjdk.java.net/~robm/4

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

That link should be: http://cr.openjdk.java.net/~robm/4244896/webrev.04/ -Rob On 31/05/12 16:05, Rob McKenna wrote: Latest version including work on the spec language: http://cr.openjdk.java.net/~robm/4244896/webrev.04/ <http://cr.openjdk.java.net/%7Erobm/4244896/webrev.03/>

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/

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

or comments: Process.java: 236 * {@link ProcessBuilder#start} and {@link Runtime#exec} are of type that "are of type" -> "are of a type ..." ProcessKillTest.sh: BIT_FLAG is now unused. Thanks, David On 1/06/2012 1:05 AM, Rob McKenna wrote: Latest version includin

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

Re: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid)

Thanks Thomas, As per Alan's mail, we're going to deal with this as a separate issue after we've discussed it. -Rob On 25/06/12 10:52, Alan Bateman wrote: On 25/06/2012 09:56, Thomas Stüfe wrote: Hi, Rob, src/solaris/native/java/lang/UNIXProcess_md.c: You never check the return code o

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

Request for review: 7179305: (fs) Method name sun.nio.fs.UnixPath.getPathForExecptionMessage is misspelled

http://cr.openjdk.java.net/~robm/7179305/webrev.01/ Thanks, -Rob

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

Codereview request: 6931128: (spec) File attribute tests fail when run as root.

Hi folks, Looking for a codereview for a spec change in jdk8. In summary, when a java application is run as root it can perform file operations regardless of the permissions attributed to that file. I.e. canExecute, canRead, canWrite would return true even though the File may not have those p

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

Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896

Hi folks, One of the tests from 4244896 failed once during nightly testing. It isn't known how much of a delay will be necessary in order for it to pass. In any case the tolerance can't really be loosened much more without making the test meaningless so I've decided to remove it. http://cr.o

Re: Request for review: 7191777: test/java/lang/ProcessBuilder/Basic.java failing intermittently due to additions for 4244896

03:18, David Holmes wrote: Hi Rob, On 16/08/2012 9:09 AM, Rob McKenna wrote: Hi folks, One of the tests from 4244896 failed once during nightly testing. It isn't known how much of a delay will be necessary in order for it to pass. In any case the tolerance can't really be loosened m

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

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: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

Hi folks, The only way I can see this test failing in this manner[*] is if we destroy the process before we begin the read. That being the case I've jacked up the sleep (giving the reader thread a little more time to get cracking) and added a check to see if the threads stack has entered a re

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/

Re: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

iting for the useCount to be bumped. On other platforms this is not an issue, I think. Martin On Thu, Oct 4, 2012 at 12:39 AM, Alan Bateman <mailto:alan.bate...@oracle.com>> wrote: On 03/10/2012 22:44, Rob McKenna wrote: Hi folks, The only way I can see this test failin

Re: RFR: 7152183: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently [sol]

in the wrapped case by assigning "s = deferred"? Sorry, that was a mistake. Rectified now. I hadn't actually exercised that code due to my while loop implementation and the fact that the problem wasn't reproducing. Thanks for spotting that. -Rob Thanks, Martin On

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

Request for review: 8000487: Java JNDI connection library on ldap conn is not honoring configured timeout

Hi folks, Seemingly when using ldap's simple authentication we perform a readReply. (an operation which is subject to com.sun.jndi.ldap.read.timeout as opposed to com.sun.jndi.ldap.connect.timeout) This makes an apparent connection to a faulty host appear to take much longer than the specified

RFR: 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java

Hi folks, Managed to remove the Thread.sleep(10) from the test when fixing 7152183. Sorry about that. http://cr.openjdk.java.net/~robm/8000817/webrev.01/ -Rob

Re: RFR: 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java

Sorry for not responding sooner, I was out for the evening. I threw this fix into our test infrastructure (jprt) before I left though, and I see it has passed. http://cr.openjdk.java.net/~robm/8000817/webrev.02/ I'm a little unclear as

Re: RFR: 8000817: Reinstate accidentally removed sleep() from ProcessBuilder/Basic.java

to also do that. I'm not sure what happens on macosx or windows - you might want to think about that. Martin On Fri, Oct 12, 2012 at 1:18 PM, Rob McKenna <mailto:rob.mcke...@oracle.com>> wrote: Sorry for not responding sooner, I was out for the evening. I threw this fix

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.

RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux

It has been suggested to me (at least twice at this stage) that these files should be merged since they're identical. This requires an adjustment in perspective from "every platform should have its own implementation" to "those platforms that differ from the norm should have their own implement

Re: RFR: 8000975: Merge UNIXProcess.java.bsd & UNIXProcess.java.linux

That is true, and I'm just working on bringing Mike's Solaris changes forward now. I hadn't considered that it would result in a difference in Mac too. I'll get this work completed and see where it stands first. -Rob On 16/10/12 17:35, Alan Bateman wrote: On 16/10/201

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

RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing the LDAP context

Hi folks, We have a hang between LdapClient / Ctx due to the fact that Connection.cleanup() calls LdapClient.processConnectionClosure which locks the unsolicited vector and in turn calls LdapCtx.fireUnsolicited which locks the eventSupport object. Unfortunately when an LdapCtx.close() occurs

Re: RFR/RFA (8u-dev) 8133253: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profile

Approved pending positive codrereview. -Rob On 19/08/15 15:57, Ivan Gerasimov wrote: Hi! The test FieldSetAccessibleTest.java fails when testing with compact3 even after fixing JDK-8080524. The reason is that the test tries to access classes which are only available in full jdk. The p

Re: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing the LDAP context

since both LdapCtx.fireUnsolicited and LdapCtx.removeUnsolicited sync on eventSupport and LdapCtx.fireUnsolicited double checks to make sure it is still unsolicited, that should be fine. -Rob On 10/08/15 14:06, Rob McKenna wrote: Hi folks, We have a hang between LdapClient / Ctx due to

RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr in getLastErrorString

Hi folks, Requesting a review of this change which switches corelibs usages of the thread-unsafe strerror over to strerror_r/strerror_s: http://cr.openjdk.java.net/~robm/8133249/webrev.01/ -Rob

Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr in getLastErrorString

Thanks Christos: On 21/09/15 17:32, chris...@zoulas.com wrote: On Sep 21, 4:53pm, rob.mcke...@oracle.com (Rob McKenna) wrote: -- Subject: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr | Hi folks, | | Requesting a review of this change which switches corelibs usages of the

Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr in getLastErrorString

the extra information from the return is potentially useful. -Rob On 23/09/15 14:14, Ivan Gerasimov wrote: Hi Rob! On 21.09.2015 18:53, Rob McKenna wrote: Hi folks, Requesting a review of this change which switches corelibs usages of the thread-unsafe strerror over t

RFR: 8135124 - com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Hi folks, I'd like to comment the ReadTimeoutTest part of this test for now as it appears to be causing intermittent failures. (on the understanding that these failures will be investigated separately) http://cr.openjdk.java.net/~robm/8135124/webrev.01/ -Rob

Re: RFR - 8133249: Occasional SIGSEGV: non thread-safe use of strerr in getLastErrorString

s non-new-line-terminated messages. Sincerely yours, Ivan On 24.09.2015 17:10, Rob McKenna wrote: Hi folks, Uploaded a newer version: http://cr.openjdk.java.net/~robm/8133249/webrev.02/ To address Rogers question, this needed to be separate from getLastErrorString because of the return type an

Re: [8u-dev] Request for review and approval: 8139863: [TESTBUG] Need to port tests for JDK-8134903 to 8u-dev

Sorry for the delay Michael, I had understood the subject to mean you were waiting on another explicit review. Approved. -Rob On 04/11/15 08:39, Michael Haupt wrote: All, the code in question has been reviewed already: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-Februa

RFR: 8132455 - com/sun/jndi/ldap/LdapTimeoutTest.java fails at handleNamingException

So unfortunately this isn't a real fix for this failing test. (intermittent, certain platforms only) However since I have enough information to investigate this problem separately I'd like to silence this specific failure in the mean time. I'll investigate the actual failure under https://bugs.

RFR: 8140344: add support for 3 digit update release numbers

Hi folks, With 7u hitting 101 shortly we've noticed that our Version parsing infrastructure balks at the extra digit. With that in mind I'd like to update the logic surrounding the parsing of version numbers and the test itself to use regex instead of the less flexible CharacterSequence method

Re: RFR: 8140344: add support for 3 digit update release numbers

ote: On 17/11/2015 14:47, Rob McKenna wrote: Hi folks, With 7u hitting 101 shortly we've noticed that our Version parsing infrastructure balks at the extra digit. With that in mind I'd like to update the logic surrounding the parsing of version numbers and the test itself to use

Re: RFR: 8140344: add support for 3 digit update release numbers

On 18/11/2015 1:30 AM, Rob McKenna wrote: I'd expect this to be superseded by 223 completely but I've cc'd verona-dev in case there are objections. At this point the fix is more for the benefit of 7 & 8. I'd be happy to mark this 9-na if that makes more sense? I'

Re: RFR: 8140344: add support for 3 digit update release numbers

You would think, but this fix isn't in jdk_util.c in 6. The test isn't in 6 either though. -Rob On 24/11/15 04:39, David Holmes wrote: On 24/11/2015 12:24 AM, Rob McKenna wrote: Thanks David, I'll mark this 9-na. (bcc'ing verona-dev) Something similar w

8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the failing subtest out into its own file and excluded it on the (intermittently) failing platforms. http://cr.openjdk.java.net/~robm/8141370/webrev.01/ -Rob

Re: 8141370: com/sun/jndi/ldap/LdapTimeoutTest.java failed intermittently

file: 26 * @run main/othervm LdapTimeoutTest cheers, -- daniel On 08/12/15 15:00, Rob McKenna wrote: Hi folks, Hopefully this fix puts this tests' failures to bed. (mind you I've thought that before) Basically I've separated the failing subtest out into its own file and exc

Re: RFR(s): 8148425: strerror() function is not thread-safe

On 27/02/16 11:20, David Holmes wrote: > On 27/02/2016 5:00 AM, Volker Simonis wrote: > >Hi Thomas, > > > >it's good that somebody finally addresses this long standing issue :) > > > >However I wonder if it would be possible to align this effort with the > >core libraries group (CC'ed). They alread

Re: RFR 9 8043477: java/lang/ProcessBuilder/Basic.java failed with: java.lang.AssertionError: Some tests failed

Eesh, Sorry Roger, I have something like this on my todo. Martin, my concern with the long delay approach is that it effectively nullifies the point of the test. Given that this test has been flakey the approach has been to simply bump the acceptable delta by another 100ms or so every time. Si

RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

Hi folks, Looking to fix a regression caused by 8042857. Basically the behaviour in 8042857 is incorrect. This fix reverts to the previous behaviour and attempts to beef up the tests a little around Ldap timeouts. http://cr.openjdk.java.net/~robm/8065238/webrev.01/ The test itself looks quit

Re: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8

Just updated the test to workaround a seemingly unrelated platform specific issue. (that only manifests on older kernels) http://cr.openjdk.java.net/~robm/8065238/webrev.02/ -Rob On 03/12/14 16:21, Rob McKenna wrote: Hi folks, Looking to fix a regression caused by 8042857. Basically the

Re: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid swap,exhaustion (jdk7u-dev)

Hi Amit, As per https://bugs.openjdk.java.net/browse/JDK-5049299, this is fixed in 7u55+ (including 8 fcs). There are some peculiarities however: On JDK8 posix_spawn is the default on Solaris & Mac. vfork is the default on Linux. On JDK7u55+ posix_spawn is the default on Mac only. fork is the

RFR: 8077822: javac does not recognize '*.java' as file if '-J' option is specified

Hi folks, Because of platform specifics the Java launcher contains some extra wildcard expansion processing on Windows. As part of this processing the list of args received by CreateApplicationArgs (java_md.c) is compared to the original list in the java launchers main method. Unfortunatel

Re: RFR: 8077822: javac does not recognize '*.java' as file if '-J' option is specified

en("-J") == 0) continue; argv = (StdArg*) JLI_MemRealloc(argv, (nargs+1) * sizeof(StdArg)); argv[nargs].arg = JLI_StringDup(arg); argv[nargs].has_wildcard = stdargs[i].has_wildcard; nargs++; } Thanks Kumar On 5/19/2015 6:58 AM, Rob

RFR: 7130985: Four helper classes missing in Sun JDK

Meant to get this sorted a while back. There was a thread on this last year ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027779.html ) A test has been added since then: http://cr.openjdk.java.net/~robm/7130985/webrev.corba/ http://cr.openjdk.java.net/~robm/7130985/webrev.j

Re: RFR: 7130985: Four helper classes missing in Sun JDK

Added some cleanup code around the BufferedReaders & the leftover test files: http://cr.openjdk.java.net/~robm/7130985/webrev.02/ -Rob On 03/06/15 16:20, Rob McKenna wrote: Meant to get this sorted a while back. There was a thread on this last year ( http://mail.openjdk.java

Re: [8u60] approval request for JDK-8062198: Add RowSetMetaDataImpl Tests and add column range validation to isdefinitlyWritable

Approved. -Rob On 05/06/15 16:39, Maxim Soloviev wrote: Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8062198 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4162bcc663dc Thanks, Maxim

Re: [8u60] approval request for JDK-8059411: RowSetWarning does not correctly chain warnings

Approved. -Rob On 05/06/15 16:45, Maxim Soloviev wrote: Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8059411 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4110a7627857 Thanks, Maxim

Re: [8u60] approval request for JDK-8066188: BaseRowSet returns the wrong default value for escape processing

Approved. -Rob On 05/06/15 16:50, Maxim Soloviev wrote: Please approve direct backport. bug: https://bugs.openjdk.java.net/browse/JDK-8066188 jdk9 change set: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/f619341171c0 Thanks, Maxim

[RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

This recently received CSR approval, so it seems like a good time to pick the codereview up again: http://cr.openjdk.java.net/~robm/8160768/webrev.08/ Referencing: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050794.html 1) I'm copying the behaviour from LdapCtxFactory.get

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

it's been pulled from the queue. > > So I would suggest exchanging: > > 115 if (isClosed()) { > 116 return null; > 117 } > 118 > 119 return result; > > with: > > return result == EOF ? null : resu

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

> 94 return pauseAfterReceipt; > 95 } > > getReplyBer() is not synchronized, so AFAICS there is a > chance that line 93 executes after another thread as got > hold of the `ber` object. > > Is that an issue? Should the `ber` object be added to > the reply

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

Yes, thanks a lot Alan. Vyom and Martin both had some very helpful feedback so I'm hoping to hear from both! -Rob On 26/10/18 15:34, Alan Bateman wrote: > On 25/10/2018 17:34, Rob McKenna wrote: > > This recently received CSR approval, so it seems like a good time to pick >

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

only allowed the queue to fill to 80% of its capacity before pausing. I agree though, it doesn't really make sense to keep that. I'll remove it. > > On 25/10/2018 21:53, Rob McKenna wrote: > > I'm planning to follow up on the test side of things with a separate > > b

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

ch delegates to the existing method after conversion. Hopefully this addresses your concerns. I'll update the CSR accordingly once this review is complete. -Rob > > > best regards, > > -- daniel > > > On 25/10/2018 17:34, Rob McKenna wrote: > > This rece

Re: [RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider

lent, in the end, to returning an Optional containing > a LdapDnsProviderResult which returns an empty list of endpoints? > I guess that's OK, I don't see any value in preventing an > LdapDnsProviderResult to have an empty endpoint list anyway. > Basically, yes. Thanks, -Rob

[RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"

Hi folks, I'd like to fix this test failure caused by 8160768. The problem is that the LdapDnsProviderResult sets the hostname to the empty String and gets passed to StartTlsResponseImpl.verify. Unfortunately StartTlsResponseImpl.verify only expects null values. Since null and the empty String ar

Re: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"

domain name; can be null. > > My personal suggestion is not to replace null to empty string("") in > "LdapDnsProviderResult" either throw some exception or just pass whatever > you got in LdapDnsProviderResult constructor. > > Thanks, > > Vyom

RFR - 8143640: Showing incorrect result while passing specific argument in the Java launcher tool

Hi folks, Looking for a review for this simple change: http://cr.openjdk.java.net/~robm/8143640/webrev.01/ Basically the windows command parser was inserting extra slashes under certain circumstances. cmdtoargs.c standalone test passes, as do the regression tests. -Rob

RFR - 8141148: LDAP "follow" throws ClassCastException with Java 8

Hi folks, Looking for a review for this change: https://bugs.openjdk.java.net/browse/JDK-8141148 http://cr.openjdk.java.net/~robm/8141148/webrev.01/ A fairly straightforward fix for a class cast problem. From the bug: As a result of https://bugs.openjdk.java.net/browse/JDK-7072353: http://hg.o

Re: JDK 9 RFR of JDK-8166054: Problem list JarURLConnectionUseCaches.java until JDK-8165988 is fixed

Sorry Joe, This passed just fine in jprt. I'll change it to othervm now. (I only noticed this problem on 8 last night) -Rob On 14/09/16 06:09, Daniel Fuchs wrote: > Hi Joe, > > Looks good to me! > > -- daniel > > On 14/09/16 18:07, joe darcy wrote: > >Hello, > > > >Until JDK-8165988

[8u-dev] RFR - 8156824: com.sun.jndi.ldap.pool.PoolCleaner should clear its context class loader

Hi folks, I'd like to backport this change to 8u-dev. The changes are straightforward enough but 8u needs some changes that were made to InnocuousThread. (strictly it doesn't need all of the changes I've made but I've made an effort to make the code look as close to 9 as possible) bug: https://b

RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

Hi folks, I'd like to get a re-review of this change: https://bugs.openjdk.java.net/browse/JDK-8139965 http://cr.openjdk.java.net/~robm/8139965/webrev/ In case the original has gone stale: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-August/042767.html -Rob

Re: RFR: 8139965 - Hang seen when using com.sun.jndi.ldap.search.replyQueueSize

gt; best regards, > > -- daniel > > On 04/09/2018 10:00, Chris Hegarty wrote: > > Rob, > > > > > On 3 Sep 2018, at 22:48, Rob McKenna wrote: > > > > > > Hi folks, > > > > > > I'd like to get a re-review of this change: &g

  1   2   3   >