RFR 8021820: Number of opened files used in select() is limited to 1024 [macosx]
aleksej.efimov at oracle.com
Mon Aug 5 11:47:09 UTC 2013
I have addressed your comments and as a result - new webrev:
The list of changes:
1. The connection to Oracle site is removed (it's not internal, but
anyway it's better not to rely on availability of external resource in
test). In current version a server socket is created and accept() method
is used for bug disclosure.
2. The cleanup method is added for closing file streams. The JTREG
successfully cleaned-up on windows after this modification.
3. common/autoconf/toolchain.m4 untouched, but 'bash
common/autoconf/autogen.sh' was executed to update generated-configure.sh.
On 07/31/2013 06:35 PM, Tim Bell wrote:
> Aleksej, Alan
> The change in common/autoconf/toolchain.m4 looks correct to me, and I
> think that is a good place to have it. Remember to run 'bash
> common/autoconf/autogen.sh' and check in the generated-configure.sh
> files as part of the changeset.
> I didn't look at the test case, but I think Alan has some good points.
> On 07/31/13 06:45 AM, Alan Bateman wrote:
>> On 31/07/2013 05:18, Aleksej Efimov wrote:
>>> Can I have a review for the following problem:
>>> The MACOSX JDK (more precisely - the java.net classes) uses the
>>> select() system call to wait for different events on sockets fds.
>>> And the default behaviour for select() on Darwin is to fail when
>>> fdset contains the fd with id greater than FDSET_SIZE(=1024). Test
>>> case in webrev illustrates this behavior.
>>> There is at least one solution for it: use
>>> -D_DARWIN_UNLIMITED_SELECT compilation flag for all macosx sources:
>>> this won't affect other parts of JDK because they are not using
>>> Currently, I have added this compilation flag to
>>> common/autoconf/generated-configure.sh and
>>> common/autoconf/generated-configure.sh. I wonder, if there is a
>>> better place where I can put this flag?
>>> The webrev: http://cr.openjdk.java.net/~aefimov/8021820/webrev.00/
>>> BUG: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021820
>> Thanks for looking into this one. The build changes look okay to me
>> but it's probably best that someone on build-dev agree to those.
>> Michael McMahon can probably explain why the net code is using select
>> for timed read/accept (I have a vague recollection of there being an
>> issue with poll due to the way that it is implemented on kqueue with
>> the result that it had to be changed to use select).
>> I think the test needs re-work. It looks to me that the it attempts
>> to connect to an Oracle internal site so that's not going to work
>> everywhere. In general we don't want the tests to be dependent on
>> hosts that may or may not exist (we had tests that used to this in
>> the past but they caused a lot of grief). It also looks like the test
>> doesn't close the 1023 files that it opens at the start and so I
>> assume this test will always fail on Windows when jtreg tries to
More information about the core-libs-dev