Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: JRuby 1.7.0.pre1
-
Component/s: None
-
Labels:None
-
Number of attachments :
Description
The line in question - https://github.com/jruby/jruby/blob/master/src/org/jruby/runtime/load/LoadServiceResource.java#L80
The getInputStream method of LoadServiceResource, only when constructed with a URL, leaks via a call to resource.openStream().
Because LoadServiceInputStream completely buffers the contents of the InputStream passed to it, you can close the InputStream created from resource.openStream() after constructing the new LoadServiceInputStream. There may be a better solution, but we've been using this workaround in a custom NonLeakingLoadServiceResource in TorqueBox for several months and it seems to work fine.
Activity
Charles Oliver Nutter
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Resolution | Fixed [ 1 ] | |
| Fix Version/s | JRuby 1.7 [ 17049 ] | |
| Assignee | Thomas E Enebo [ enebo ] | Charles Oliver Nutter [ headius ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
See TorqueBox's fixed version here - https://github.com/torquebox/torquebox/blob/3b772e24514203786d0b4a0113a4cb239b19b1f1/modules/core/src/main/java/org/torquebox/core/runtime/NonLeakingLoadServiceResource.java
Not that our fix of closing the InputStream in LoadServiceResource only works because we know the implementation details of LoadServiceResourceInputStream and motivated by our need to find an easy way to hook into JRuby's LoadService implementation without too much effort. The correct long-term fix probably shouldn't rely on knowing the internals of LoadServiceResourceInputStream.
Maybe a better solution is to change LoadServiceResourceInputStream to only have the byte array constructor and push the buffering of the InputStream to a byte array into LoadServiceResource, which can then safely close the stream after all the contents are buffered?