Problems persist in KQueueSelectorProvider (Mac) in 7u6 ea

Jason T. Greene jason.greene at redhat.com
Sat Aug 11 22:27:38 PDT 2012


I spoke too soon. This change does not work on all combinations of VM 
and OSX version.

On 8/11/12 11:50 PM, Jason T. Greene wrote:
> I have been pretty short on time with paternity leave, but I was able to
> debug this a little bit further. One of the main issues is that interest
> ops is zero on keys that kqueue is returning, hence the tight loop.
>
> There appears to be thread safety issues with EV_ADD/EV_DELETE from
> multiple threads. Synchronizing KQueueArrayWrapper.setInterest(int,int)
> seems to resolve both issues, at least so far.
>
> I do wonder if an alternative approach using EV_ENABLE/EV_DISABLE might
> eliminate the need for extra locking.
>
>
> On 8/10/12 6:36 PM, David M. Lloyd wrote:
>> We're consistently seeing issues under load on Mac with
>> KQueueSelectorProvider.
>>
>> There are two possibly related symptoms: the KQueueSelectorImpl is going
>> into a mode where select() does not block, despite the continued
>> emptiness of the selected key set; and FileDispatcherImpl#preClose0 is
>> hanging, presumably in dup2(), trying to close a socket.
>>
>> My current hypothesis that some evil race condition exists and is being
>> tripped between kqueue and dup2 (a relatively rare way to close a
>> socket, at least until NIO came along I guess).  My thought though is
>> that sockets should not be preclosed this way: instead it would be
>> better to use shutdown(fd, SHUT_RDWR), which would effectively preclose
>> the socket and hopefully dodge this issue.
>>
>> I'm hopefully going to have time to try out a patch which does this, but
>> I'm taking a couple weeks off starting tonight so I may not have time,
>> so we shall see.
>
>


-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


More information about the nio-dev mailing list