possible NIO selector leak in 7u25

[David M. Lloyd]

On 7/4/13 4:42 AM, Alan Bateman wrote:
> On 04/07/2013 09:36, Bernd Eckenfels wrote:
>> Hello,
>>
>> we see a possible handle/selector leak very similiar to this bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118373
>>
>> We see on linux unix domain sockets and on windows /dev/afd handles
>> which are not backed up by any socket/selector/handle/channel in the
>> heapdump. This is a applicxation using NIO (via JBoss XNIO). We would
>> like to nail down the source of it and therefore it would be good if
>> we have the actual code from the old bug above "e.java" to see if this
>> helps us to reproduce the problem. Can any Oracle developer with
>> access to it sent it? (and cvonfirm the bug is fixed)
>>
>> In our case we see >500 of those internal sockets, but the related tcp
>> sockets (and java objects) are gone.
>>
>> Bernd
>
> Do you know if JBoss XNIO uses socket adapters to do timed reads? These
> were implemented as temporary Selectors and cached on a per thread
> basis. We've replaced this in jdk8 but for jdk7 and older then it is
> possible to have scenarios where there are a lot of threads or
> short-lived threads and the temporarily Selectors hang around until they
> are GC'ed. If you are using lsof or equivalent then it would be visible
> as an apparently build up of Unix domain sockets. You mention that the
> heap dump doesn't appear to have references and that make sense if the
> heap dump is generated from only the live objects (would be interesting
> to know if the Unix domain sockets are closed as as result of a heap
> dump that does a full GC first).
>
> There isn't an "e.java" attached to the bug. This bug is actually a
> "shadow bug" for something that came via another support/customer system
> so it has been filtered. When Rob fixed 7118373 then he wasn't able to
> come up with a reliable test case that demonstrated the issue in a
> reasonable amount of time.
>
> So are you able to duplicate the issue in your environment? I'm just
> wondering if you could try a preview build of 8 or event 7u40 to double
> check that the issue still duplicates.

XNIO uses Selectors (usually PollSelectorImpls) which are cached per 
thread in order to mix blocking and non-blocking I/O.  If you are 
starting many short-lived threads and doing blocking operations on XNIO 
channels then this might explain what is happening.  The answer is 
basically "don't do that".

-- 
- DML