-
Notifications
You must be signed in to change notification settings - Fork 517
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ring.util.response/resource-response triggers JDK bug and leaks file descriptors #462
Comments
We're also running into this bug. The more informative JDK bug is: JDK-6956385, as JDK-8224095 is marked as a duplicate of that. |
Given that this bug appears to be fixed in modern versions of the JDK, it doesn't seem worth adding a potentially costly workaround. Perhaps something could be added to the docstring to suggest |
https://github.com/ring-clojure/ring/blob/master/ring-core/src/ring/util/response.clj#L288 calls .getLastModified which leaks a file descriptor per https://bugs.openjdk.java.net/browse/JDK-8224095
This led to my service failing due to running into the file descriptor ulimit, netty failing to accept new connections, etc. Problem was clear through through /proc/xxx/fd growth and then confirmed with a YourKit memory dump which showed 16K+ Not Closed Files with creation backtraces through connection-last-modified.
Depending on usage pattern and garbage collection this issue may be hidden by the finalizer. However when under load without GC pressure, the file descriptors can be exhausted before this happens.
Workaround: replace use of resource-response with something that bypasses the getLastModified call. I'm considering memoizing all my resource responses (using byte[] bodies) as I have a very small footprint of resources I want to serve.
The text was updated successfully, but these errors were encountered: