Glad to hear you got to the bottom of it.
-Rob
On 08/07/13 23:22, Bernd Eckenfels wrote:
Hello,
we found a cause for the leak, we did not use the latest xnio-nio
release. Looking at the NioTcpChannel code I guess that for example
this commit could fix a potential problem (we shutdown
Hello,
we found a cause for the leak, we did not use the latest xnio-nio release.
Looking at the NioTcpChannel code I guess that for example this commit
could fix a potential problem (we shutdown r+w before we close, which
would not be passed on by the older xnio-nio):
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
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
On 04/07/2013 19:43, David M. Lloyd wrote:
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
Hello,
I will have a look at 7u40 and 8 as soon as I get some time. But I dont
think it is thread(caching) related as it does not show up in the heapdump
(and we have a controled thread creation rate). It looks more like some
close/cancel interactions (and a real leak).
I will let you
On 7/4/13 1:53 PM, Alan Bateman wrote:
On 04/07/2013 19:43, David M. Lloyd wrote:
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
