-
Bug
-
Resolution: Fixed
-
Major
I have a job that dynamically creates jobs using the CLI. I have noticed that since installing the job, which verifies the existing of jobs by calling 'get-job', Jenkins is leaking file descriptors. I am currently making around 40 calls per build, which runs on every CVS commit. I have a job setup to monitor the number of FD's in /proc/$jenkins_pid/fd. Calling garbage collection in the JVM doesn't release the FD's and thus the only cure is to restart Jenkins before the number of files reaches the Open file ulimit. I have set my ulimit to 65356 so I don't have to reboot so frequently. I restarted Jenkins at 7:49 this morning and the file descriptor count is currently at 6147 files; it's now 12:10 in the afternoon, so it's been steadily leaking FD's at approximately 1500 per hour.
- is related to
-
JENKINS-23572 Repeated calls to jenkins cli results in Too many open files exception on the master
-
- Resolved
-
Code changed in jenkins
User: Kohsuke Kawaguchi
Path:
src/main/java/hudson/remoting/SocketChannelStream.java
http://jenkins-ci.org/commit/remoting/c90fc463923cc7f4a8907a0b352204f3d561cc55
Log:
[FIXED JENKINS-23248] Seeing strange "Transport endpoint is not connected" exception
s.shutdownInput() fails with the following exception, even though s.isInputShutdown() is reporting false:
java.net.SocketException: Transport endpoint is not connected
at sun.nio.ch.SocketChannelImpl.shutdown(Native Method)
at sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:667)
at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:378)
at hudson.remoting.SocketChannelStream$1.close(SocketChannelStream.java:39)
at sun.nio.ch.ChannelInputStream.close(ChannelInputStream.java:113)
at javax.crypto.CipherInputStream.close(CipherInputStream.java:296)
at java.io.BufferedInputStream.close(BufferedInputStream.java:468)
at hudson.remoting.FlightRecorderInputStream.close(FlightRecorderInputStream.java:112)
at hudson.remoting.ChunkedInputStream.close(ChunkedInputStream.java:102)
at hudson.remoting.ChunkedCommandTransport.closeRead(ChunkedCommandTransport.java:50)
at hudson.remoting.Channel.terminate(Channel.java:795)
at hudson.remoting.Channel$CloseCommand.execute(Channel.java:951)
at hudson.remoting.Channel$2.handle(Channel.java:475)
at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60)
This bug report may be related: http://bugs.java.com/view_bug.do?bug_id=4516760
If we fail to call s.close(), a socket will leak, so swallowing this exception and have the code execute "s.close()"
Compare: https://github.com/jenkinsci/remoting/compare/d1905acf329e...c90fc463923c