]
Tomaz Cerar commented on WFLY-8160:
-----------------------------------
Looking at the output of the file leak detector, there are no leaks in any of WildFly
related code.
However, you do have somewhat a problem with **LOTS** of open sockets that are opened by
zeromq.
This is the trace that repeates pretty much through the whole file:
{noformat}
2017-03-23 17:30:38,412 ERROR [AbstractLoggingWriter] (iothread-2) Opened socket channel
by thread:iothread-2 on Thu Mar 23 17:30:38 PDT 2017
at sun.nio.ch.SocketChannelImpl.<init>(SocketChannelImpl.java:108)
at sun.nio.ch.SelectorProviderImpl.openSocketChannel(SelectorProviderImpl.java:60)
at java.nio.channels.SocketChannel.open(SocketChannel.java:145)
at zmq.TcpConnecter.open(TcpConnecter.java:292)
at zmq.TcpConnecter.startConnecting(TcpConnecter.java:215)
at zmq.TcpConnecter.timerEvent(TcpConnecter.java:206)
at zmq.IOObject.timerEvent(IOObject.java:129)
at zmq.PollerBase.executeTimers(PollerBase.java:131)
at zmq.Poller.run(Poller.java:187)
at java.lang.Thread.run(Thread.java:745)
{noformat}
In linux open socket channel also consumes file descriptor and this is most probably your
root cause of the issue.
Webservice response File Descriptor leak
----------------------------------------
Key: WFLY-8160
URL:
https://issues.jboss.org/browse/WFLY-8160
Project: WildFly
Issue Type: Bug
Components: Web Services
Affects Versions: 9.0.0.Final, 9.0.2.Final, 10.1.0.Final
Environment: JDK: jdk1.8.0_121, jdk1.8.0_66
WilfFly : wildfly-10.1.0.Final, wildfly-9.0.2.Final , wildfly-9.0.0.Final
OS: Red Hat Enterprise Linux Server release 7.1 (Maipo)
Hardware: 64 bit 4 core
Reporter: Mahesh Reddy
Assignee: Alessio Soldano
Attachments: BioMatcherWebserviceImpl.java, SOAP_REQUEST.txt, SOAP_RESPONSE.txt,
file-leak-detector_output.txt
We are getting File descriptor leak when wildfly responds to webservice call.
I think this happens if the webresvice response is huge complex structure,
I confirmed by adding the sleep just before the returning from the webservice method and
checking lsof -p <pid>, And again checking it after client receives the response,.
I notice for each webservice call, 2 file descriptors are open and never closed.