Re: java.io.File
Mark wrote:
Lew wrote:
(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,
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
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 hav=
e
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.
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/.
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 fil=
es?
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.
Correct.
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?
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.
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?
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=
..
--
Lew