Regression in EPollArrayWrapper causes NPE when fd > 64 * 1024

[Seán Coffey]

Looks good to me also. Thanks for jumping on this Norman, Alan.

regards,
Sean.

On 18/09/13 13:25, Norman Maurer wrote:
>
>
> Am 18.09.2013 um 14:16 schrieb Alan Bateman <Alan.Bateman at oracle.com 
> <mailto:Alan.Bateman at oracle.com>>:
>
>> On 18/09/2013 11:20, Norman Maurer wrote:
>>> Hi Alan,
>>>
>>> I tried to find one of those "existing stress-tests" but was not 
>>> able yet. Can you just tell me where I can find one so I can 
>>> actually write a test-case based on one of them.
>>>
>> Yeah, the Selector tests in the jdk/test tree are a bit of mixed bag 
>> tests for various long fixed issues.
>>
>> One thing that I remembered after our exchange is that the Selector 
>> implementations that we have for Solaris use the same approach for 
>> queuing updates. This came about when we re-worked the /dev/poll 
>> Selector to fix a number of performance and reliability issues. It's 
>> also in the relatively new port based Selector which I'd like to see 
>> made the default on Solaris at some point.
>>
>> So while only the epoll Selector has the problem (due to the kill 
>> logic) then I think it would be best if we provide a way to test all 
>> of the Selectors. To that end, I've added a special property to 
>> select the limit that we can use for testing. Your suggestion to use 
>> reflection would work too, as would having a test that adds to 
>> sun.nio.ch <http://sun.nio.ch>. The first approach seems the simplest 
>> so I've put a webrev here with the changes:
>>
>> http://cr.openjdk.java.net/~alanb/8024883/webrev/
>>
>> It means we can run jtreg with 
>> -vmoption:-Dsun.nio.ch.maxUpdateArraySize=N and it will run all of 
>> the tests with this setting. This is the same approach when you want 
>> to test with an alternative Selector implementation. To ensure that 
>> there is at least some coverage in normal test runs then I've 
>> modified the test description of two tests so that they re-run with 
>> this property set to a smallish value.
>>
>> Let me know if you are agree with this. I realize this is extending 
>> the scope of your original bug report and patch a bit.
>>
>> -Alan
>>
>>
>>
>
> Looks good…  Thanks for reviewing my bug report and the patches. Have 
> this tested also for other Selectors makes a lot of sense.
>
>
> ---
> Norman Maurer
> nmaurer at redhat.com <mailto:nmaurer at redhat.com>
>
> JBoss, by Red Hat
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130918/2f75e504/attachment.html