As another data-point...
Our CI build had been failing on an environment with ulimit -f of 1024. I
altered the VFSLoadService to work purely with File-constructed
LoadServiceResources instead of URL-constructed ones. Our tests passed
successfully.
Our VFSLoadService subclasses the stock LoadService, and I've changed all
points in our subclass from URL->File. But there could still be more living
within the stock LoadService. I have not fully investigated.
If I can get another pair of eyes on this to verify that I'm not chasing
waterfalls, I'll be glad to prepare a patch for the codepaths in question.
Thanks,
-Bob
On Apr 21, 2011, at 11:42 PM, Bob McWhirter wrote:
> Heya Nick (and others)--
>
> I know I've mangled the heck out of TorqueBox's LoadService implementation,
> but poking around the code, I'm wondering if JRuby itself might not be
> leaving streams dangling at times.
>
> I see creation of LoadServiceResources, with either a File or a URL. In my
> case, we're using a lot of URLs.
>
> In the URL case, LoadServiceResource#getInputStream() opens the URL's
> inputStream, feeds it to a LoadServiceResourceInputStream, which immediately
> buffers the entire contents, but does not close the InputStream.
>
> In the case of a File-backed LoadServiceResource, the File is also read
> completely, but is then closed.
>
> Wondering if I'm missing some implicit or explicit close() occurring
> somewhere I'm not looking.
>
> Thanks,
>
> -Bob
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
