Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: java.io.File Date: Fri, 2 Dec 2011 14:02:05 -0800 (PST) Organization: http://groups.google.com Lines: 141 Message-ID: <32687452.648.1322863326052.JavaMail.geo-discussion-forums@prjr26> References: <1754083.312.1322839502470.JavaMail.geo-discussion-forums@prjr26> <5ushd716i6g4qncg620f49ancol20af51f@4ax.com> <20850741.465.1322842636010.JavaMail.geo-discussion-forums@prnu18> <4puhd7h1qgr5rq3cgeebmrt64cc7qfn004@4ax.com> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 2620:0:1000:fd2b:224:d7ff:fe69:5838 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1322863449 19294 127.0.0.1 (2 Dec 2011 22:04:09 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 2 Dec 2011 22:04:09 +0000 (UTC) In-Reply-To: <4puhd7h1qgr5rq3cgeebmrt64cc7qfn004@4ax.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2620:0:1000:fd2b:224:d7ff:fe69:5838; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10437 Mark wrote: > Lew wrote: >=20 > (BTW your posts appear to have no line wrapping) I cannot control how my posts appear in your newsreader. Your lines appear not to wrap in my newsreader also. > >Mark wrote: >>> Lew wrote: >>>> Mark wrote: >>>>> Can a java.io.File object use a OS file descriptor? I am trying to >>>>> find the source of a fd leak in a[n] application. >>>> >>>> At some point, depending on the operations performed by the 'File' ins= tance,=20 >>>> there may be a file descriptor involved, and then the 'File' instance = certainly >>>> does use it, at least indirectly via JVM system calls that proxy to OS= system >>>> calls. >>>> >>>> From a Java perspective you should look for unclosed I/O streams/chann= els and=20 >>>> packratted 'File' instances rather than file descriptors. >>>=20 >>> I've done a code inspection and the streams are all explicitly closed. >>> There are a number of File objects used and I notice that File does >>> not have a close() method so we have to rely on GC. >> >> If there were a 'close()' method, as there is with streams, it would hav= e=20 >> nothing to do with GC. 'close()' is for resources (such as file handles= ). >> GC is for heap memory. I only suggested checking for packratted 'File' >> instances as a foolish guess. Now that I think about it, it is highly >> unlikely that unclaimed instances would have anything to do with your is= sue. >=20 > AFAIK many classes have a close() method to allow any underlying OS > resources to be explicitly freed without needing to wait for the > dispose() method to do this. If the File method does uses file What 'dispose()' method? 'File' doesn't have one. 'FileOutputStream' does= n't have one. 'FileInputStream' doesn't have one. None of their ancestor = classes up through 'Object' has one. > descriptors then we may assume that these could be left open until the > object is destroyed during GC. No, we cannot assume any such thing, nor can we even assume any given 'File= ' instance, or any other class instance, will be collected ever. 'FileInputStream', but not all 'InputStream' types, and 'FileOutputStream',= but not all 'OutputStream' types, do have a 'finalize()' method that might= , eventually, release file resources assuming the instances go through two = GC cycles, but there's no assurance that that will happen. >>>> Of course I'm shooting in the dark since you've said absolutely nothin= g about >>>> your application, much less provided an http://sscce.org/. >>>=20 >>> I know. It would be difficult to produce an example since I cannot >>> reproduce the problem myself - it happens in production only and I >>> don't have any access there. >>>=20 >>> I get the exception: >>> java.io.IOException: Cannot run program "/path/to/script": >>> java.io.IOException: error=3D24, Too many open files >> >> Do you have any reason to believe it's your program that holds those fil= es? >=20 > The reporter of the problem believes so. Some people believe in Creationism. It doesn't make their belief valid. You need evidence. >>> The script is called via ProcessBuilder object and I don't see any >>> obvious problems there. >> >> Or subtle ones either, I guess. >=20 > Correct. >=20 >> An irreproducible problem involving disparate runtime environments (insi= de >> and outside the JVM), executing black-box code on an undisclosed platfor= m >> yielding an error message possibly originated by an entity outside the J= VM >> with no data forthcoming - is that the issue with which you request assi= stance? >=20 > The error message did orginate within the JVM. I know the problem is > a tricky one which is why I specificly worded it to relate to the > java.io.File class. The message originated in the JVM; it doesn't mean that the problem did. >> Note: the preceding paragraph implies a path forward, in that a problem= statement >> illuminates prospective solutions. In case you missed it, the path forw= ard is >> for you to gain visibility into that plethora of unknowns, or sadly repo= rt >> to your client, as we do to you, that with nothing to go on you have not= hing to offer. >=20 > Unfortunately I work in the real world. I often get reported problems My advice is for the real world. Duh. > with inadequate information. Usually I can work out what is going on There's a difference between inadequate information and zero information. = You have given us zero information. > even though it's like doing a jigsaw puzzle with most of the pieces > missing. I don't like telling clients that I have nothing to offer in > case they tell me the same ;-) That's why I gave you advice on how to gather more information. You have t= o know /something/ in order to fix the problem, don't you? >> Visibility involves things like logging. You do use logging, don't you? >=20 > The author of the code did use logging. It's not sufficiently > detailed to be of much use though. Thus illustrating my point that programmers write terrible logs. I hear your admirable commitment to do some good, but honestly you need a l= ot more information than you have shared here to even begin. I also hear y= our rejection of my advice to gather such information. Good luck with that= . --=20 Lew