Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!border3.nntp.ams.giganews.com!Xl.tags.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!local2.nntp.ams.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail NNTP-Posting-Date: Mon, 05 Dec 2011 09:14:19 -0600 From: Mark Newsgroups: comp.lang.java.programmer Subject: Re: java.io.File Date: Mon, 05 Dec 2011 15:14:18 +0000 Message-ID: <8fnpd79eq3grdv0vb4vul24vq5j49os748@4ax.com> Cancel-Lock: sha1:pVd7DGgIuHICj47RXlbVFO11cPk= References: <1754083.312.1322839502470.JavaMail.geo-discussion-forums@prjr26> <5ushd716i6g4qncg620f49ancol20af51f@4ax.com> <20850741.465.1322842636010.JavaMail.geo-discussion-forums@prnu18> <4puhd7h1qgr5rq3cgeebmrt64cc7qfn004@4ax.com> <32687452.648.1322863326052.JavaMail.geo-discussion-forums@prjr26> X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NFilter: 1.2.0 Lines: 143 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-zWTEBPETz1KYcuZPQN6qW72dc7/OEhwYJEXS9VHmRLzWhQzKbyOiGMaIWanc7649u5JLda/L8r0RUDA!ydR55TTD/HFlKhzEpmYJ/9RTpBWJtU9BUc/5xz046DdhusoSOt2JV4iRlSGkhdL5G/PPBdo8mn/u!PWzAOlq/puiGFYSCbQk= X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 7491 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10528 On Fri, 2 Dec 2011 14:02:05 -0800 (PST), Lew wrote: >Mark wrote: >> Lew wrote: >> >> >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' instance, >>>>> 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/channels and >>>>> packratted 'File' instances rather than file descriptors. >>>> >>>> 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 have >>> 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 issue. >> >> 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' doesn'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. Unless the Java class has been badly written we can assume that when/if the object is collected then any OS resources that it used would also be freed. Would you agree with this? We also see that File does not have a close(), dispose() or similar method. Therefore, if the object does use any OS resources, there is no way for the programmer to force them to be released. >'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. Which, presumably, they have close() methods defined. >>>>> Of course I'm shooting in the dark since you've said absolutely nothing about >>>>> your application, much less provided an http://sscce.org/. >>>> >>>> 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. >>>> >>>> I get the exception: >>>> java.io.IOException: Cannot run program "/path/to/script": >>>> java.io.IOException: error=24, Too many open files >>> >>> Do you have any reason to believe it's your program that holds those files? >> >> The reporter of the problem believes so. > >Some people believe in Creationism. It doesn't make their belief valid. Oh Boy. >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. >> >> Correct. >> >>> An irreproducible problem involving disparate runtime environments (inside >>> and outside the JVM), executing black-box code on an undisclosed platform >>> yielding an error message possibly originated by an entity outside the JVM >>> with no data forthcoming - is that the issue with which you request assistance? >> >> 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 forward is >>> for you to gain visibility into that plethora of unknowns, or sadly report >>> to your client, as we do to you, that with nothing to go on you have nothing to offer. >> >> 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. Wrong. I have given 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 to know /something/ in order to fix the problem, don't you? > >>> Visibility involves things like logging. You do use logging, don't you? >> >> 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. Which programmers? >I hear your admirable commitment to do some good, but honestly you need a lot more >information than you have shared here to even begin. I also hear your rejection >of my advice to gather such information. Good luck with that. I have not rejected your advise, just explained why I had not yet followed it. I realize this is not an ideal situation but I have two choices: 1. To try to do something even without adequate information. 2. Sit on my ass an do nothing until such time as I get more information. I chose (1). It sounds like you prefer (2).