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

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: 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

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

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

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 [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 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 [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 [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 [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

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: 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: 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 [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 >

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] 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] 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

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: 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

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

> 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: 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

[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

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

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

[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

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

n't need this try block > > Line 96 : constant name does not follow Java naming convention > > Line 105: you can use try-with-resources this will avoid some boilerplate. > > Thanks, > Vyom > > On Tuesday 05 December 2017 11:18 PM, Rob McKenna wrote: > >As thi

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

As this enhancement is limited to JDK10 this frees us up to explore a different approach. http://cr.openjdk.java.net/~robm/8160768/webrev.06/ In this webrev we're using the Service Provider Interface to load an implementation of the new LdapDnsProvider class. Implementations of this class are res

Re: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char

Further testing has shown the escaping to be necessary. Apologies folks, I'm withdrawing this review. -Rob On 06/07/17 04:57, Rob McKenna wrote: > Thanks Vyom, updated test at: > > http://cr.openjdk.java.net/~robm/8177806/webrev.02/ > > The sleep proved necessary in a

Re: [10] 8177806: ldapContext.unbind not handling ldap entry with esc char

othervm LdapEscapeTest > */ > > Thanks, > > Vyom > > > On Thursday 06 July 2017 04:14 AM, Rob McKenna wrote: > >Hi folks, > > > >Looking for a review for the following change. > > > >NameImpl.java is stripping escape characters unnecessari

[10] 8177806: ldapContext.unbind not handling ldap entry with esc char

Hi folks, Looking for a review for the following change. NameImpl.java is stripping escape characters unnecessarily: http://cr.openjdk.java.net/~robm/8177806/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8177806 Thanks, -Rob

RFR: 8180949

Hi folks, Looking for a review for this fix which repairs a push containing an older revision of the approved change: http://cr.openjdk.java.net/~robm/8180949/webrev.01/ -Rob

Re: RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout

thrown in createConnection, it can't return the > connection that was created > and so it should close it. > > I would close the connection at line 298, before throwing the exception. > > Roger > > On 5/10/2017 3:25 PM, Rob McKenna wrote: > >Hi folks, > > >

RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout

Hi folks, Looking for a review of the following simple change: https://bugs.openjdk.java.net/browse/JDK-8175131 http://cr.openjdk.java.net/~robm/8175131/webrev.01/ Note: I've deliberately limited the connection closure to the described case. If however you feel that it should be applied generall

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

thread "main" java.lang.NullPointerException > at java.base/java.util.Hashtable.put(Hashtable.java:474) > at > java.naming/com.sun.jndi.ldap.LdapCtx.setDomainName(LdapCtx.java:2346) > at > java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFact

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

PROVIDER).equals("")) > > I'd suggest to simplify this and make a single lookup: > > String providerClass = env.get(LdapCtx.DNS_PROVIDER); > if (providerClass != null && !providerClass.isEmpty()) { > ... >

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

New webrev with updated test here: http://cr.openjdk.java.net/~robm/8160768/webrev.03/ -Rob On 26/01/17 04:03, Rob McKenna wrote: > Ack, apologies, thats what I get for rushing. (which I suppose I'm doing > again) That code was actually supposed to be in the getDnsUrls method. &

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

; >Note, this wraps the SecurityException in a NamingException. Presumably > >its better to throw something than simply leave the default value in > >place, but feedback appreciated! > > > >-Rob > > > >On 25/01/17 04:31, Rob McKenna wrote: > >>Hi fo

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

than simply leave the default value in place, but feedback appreciated! -Rob On 25/01/17 04:31, Rob McKenna wrote: > Hi folks, > > I'm looking for feedback on this suggested fix for the following bug: > > https://bugs.openjdk.java.net/browse/JDK-816076 > http://cr.op

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

Hi folks, I'm looking for feedback on this suggested fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-816076 http://cr.openjdk.java.net/~robm/8160768/webrev.01/ This is something that has come up a few times. Basically in certain environments (e.g. MS Active Directory) there i

Re: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

his as a suggestion > for a simpler (and possibly insufficient) alternative ... > > best regards, > > -- daniel > > On 14/12/16 15:59, Rob McKenna wrote: > >Hi folks, > > > >Looking for a review of this change: > > > >http://cr.openjdk.java.n

Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections

Hi folks, Looking for a review of this change: http://cr.openjdk.java.net/~robm/8169465/webrev.01/ This is necessary to fix a potential problem where recursive ldap calls can potentially cause a deadlock with the PoolCleaner thread. See: https://bugs.openjdk.java.net/browse/JDK-8169465 -Ro

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

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

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

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: 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

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: 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

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

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

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

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.

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

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

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

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

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

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: 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

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

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: [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

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-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: 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

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: 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: 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: 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

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

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 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

Re: RFR: 8030166: java/lang/ProcessBuilder/Basic.java fails intermittently: waitFor took too long

Thanks Roger, -Rob On 31/07/14 14:11, roger riggs wrote: Hi Rob, The proposed update is fine. Maybe there is some AIX specific reason for making an exception for AIX. Roger On 7/28/2014 9:28 AM, Rob McKenna wrote: Hi Roger, I think that may be a question for the AIX folks to answer as

Re: RFR: 8030166: java/lang/ProcessBuilder/Basic.java fails intermittently: waitFor took too long

s like pretty simple; but I'm not keen on having the timeouts vary by architecture. I'd just increase it for all. Roger On 7/24/2014 4:57 PM, Rob McKenna wrote: Hi folks, It seems that with the testing of fastdebug and -Xcomp modes we're stretching the limits set by the test. Ti

RFR: 8030166: java/lang/ProcessBuilder/Basic.java fails intermittently: waitFor took too long

Hi folks, It seems that with the testing of fastdebug and -Xcomp modes we're stretching the limits set by the test. Timeout wack-a-mole continues: http://cr.openjdk.java.net/~robm/8030166/webrev.01/ -Rob

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

xisting 32k is being used? The reaper has very limited processing to do and there is one thread for every process spawned. Roger On 7/15/2014 1:46 PM, Rob McKenna wrote: Hi folks, A very simple change suggested by Martin a while back in another review. I'm just getting

Re: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2

much of the existing 32k is being used? The reaper has very limited processing to do and there is one thread for every process spawned. Roger On 7/15/2014 1:46 PM, Rob McKenna wrote: Hi folks, A very simple change suggested by Martin a while back in another review. I'm just getting ar

Re: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2

And as in that review you have managed to intercept me before I made a small correction. In this case to the subject. I'm beginning to suspect you're a highly sophisticated bot. -Rob On 15/07/14 18:48, Martin Buchholz wrote: Looks good to me! On Tue, Jul 15, 2014 at 10:

8050044: (process) Increase reaper thread native stack size by a factor of 2

Hi folks, A very simple change suggested by Martin a while back in another review. I'm just getting around to it now: bug: https://bugs.openjdk.java.net/browse/JDK-8050044 webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/ Martins comments: http://mail.openjdk.java.net/pipermail/cor

RFR: 7130985: Four helper classes missing in Sun JDK

Hi folks, Looking for a review for the following: bug: https://bugs.openjdk.java.net/browse/JDK-7130985 webrev: http://cr.openjdk.java.net/~robm/7130985/webrev.01/ As per the bug report: The IDLtoJava spec clearly specifies the need of the helper class (not the Holder) for these files. But the

RFR - 8041451: com.sun.jndi.ldap.Connection:ReadTimeout should abandon ldap request

Hi folks, Very simple fix to ensure that a slow server isn't left waiting around for a request we have already given up on. http://cr.openjdk.java.net/~robm/8041451/webrev.01/ -Rob

RFR - 8042857: 14 stuck threads waiting for notification on LDAPRequest

Hi folks, A simple fix to eliminate a possible infinite loop when an Ldap Connection cannot contact the server. http://cr.openjdk.java.net/~robm/8042857/webrev.01/ -Rob

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

Great to see this getting in. Thanks Peter! -Rob On 12/05/14 16:51, Peter Levart wrote: On 05/07/2014 11:04 PM, Martin Buchholz wrote: Hi Peter, Your last version version looks very good. Approved! I'm reduced to asking you to fix ancient buglets of mine. *"I'd spell creat with an e.

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

Mac OSX testing was clean. -Rob On 01/04/14 16:43, Peter Levart wrote: On 04/01/2014 03:49 PM, roger riggs wrote: Hi Peter, The design using enum for the os dependencies does not make it possible to include only the support needed for a particular platform at build time. Every implementa

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

Hi Peter, Yup, I'll give this a whirl. -Rob On 01/04/14 14:16, Peter Levart wrote: Hi Alan, Volker, Thanks for sharing the info and for testing on AIX. Here's the updated webrev that hopefully includes the correct "dispatch on os.name" logic. I included "Solaris" as an alternative to "S

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

Hi folks, Roger Riggs (cc'd) may want to chip in here as he's looking at the reaper thread arrangement in 9 at the moment. On another note, I too support the merging of those files. I didn't think there was much appetite for it at the time so I must admit this fell down my todo list. Looking

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

s, alignments and overhead) seem to increase over time. But I'd put that into a separate change. Thanks for the comment, I'll take an AI. -Rob On Fri, Mar 21, 2014 at 11:23 AM, Rob McKenna <mailto:rob.mcke...@oracle.com>> wrote: ..just realised I had an out of

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

..just realised I had an out of date webrev up there, I've just updated in place in case anyone is looking at it. -Rob On 21/03/14 17:43, Rob McKenna wrote: Hi folks, I'd like to push this change into JDK8 & 7. There is other work going on in 9 which will supersede this f

RFR: 8034944: (process) Improve subprocess handling on Solaris

Hi folks, I'd like to push this change into JDK8 & 7. There is other work going on in 9 which will supersede this fix so there is likely no point in pushing to that release. This is backport of the threadpool specific changes from https://bugs.openjdk.java.net/browse/JDK-6944584 along with s

Re: RFR: 7152892: some jtreg tests fail with permission denied

Sorry Mandy, I totally missed your reply. I'll get this resolved separately. -Rob On 10/02/14 15:43, Mandy Chung wrote: On 2/7/2014 10:44 AM, Rob McKenna wrote: Hi folks, When files are copied by our test harness the permissions are left unchanged. This can cause trouble for

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: 7152892: some jtreg tests fail with permission denied

Hi folks, When files are copied by our test harness the permissions are left unchanged. This can cause trouble for a few tests when the test folder is read only. http://cr.openjdk.java.net/~robm/7152892/webrev.01/ -Rob

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

RFR: 8029525 - java/lang/ProcessBuilder/Basic.java fails intermittently

This failure cropped up again and Roger Riggs spotted that I was looking at it from completely the wrong direction. He contributed the following fix: http://cr.openjdk.java.net/~robm/8029525/webrev.01/ This is to avoid a race between: thread.interrupt(); p.destroy(); Hoping to get this review

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

Re: RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug

fix. On Tue, Nov 19, 2013 at 11:27 AM, Alan Bateman mailto:alan.bate...@oracle.com>> wrote: On 19/11/2013 16:46, Rob McKenna wrote: Hi folks, Running this test with fastdebug binaries results in a few warning messages getting lumped into

RFR: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug

Hi folks, Running this test with fastdebug binaries results in a few warning messages getting lumped into the commandOutput. I've decided to filter these test wide. https://bugs.openjdk.java.net/browse/JDK-6703075 http://cr.openjdk.java.net/~robm/6703075/webrev.01/ -Rob

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

  1   2   3   >