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
