Given my own experimentation, I do think URL-based LoadServiceResource leaks
file descriptors.
I'lll prepare a patch.
-Bob
On Apr 23, 2011, at 10:39 AM, Bob McWhirter wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
