Re: java.io.File
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' insta=
nce,
there may be a file descriptor involved, and then the 'File' instance ce=
rtainly
does use it, at least indirectly via JVM system calls that proxy to OS s=
ystem
calls.
From a Java perspective you should look for unclosed I/O streams/channel=
s 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 n=
othing to do with GC. 'close()' is for resources (such as file handles). =
GC is for heap memory. I only suggested checking for packratted 'File' ins=
tances as a foolish guess. Now that I think about it, it is highly unlikel=
y that unclaimed instances would have anything to do with your issue.
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 script is called via ProcessBuilder object and I don't see any
obvious problems there.
Or subtle ones either, I guess.
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 assista=
nce?
Note: the preceding paragraph implies a path forward, in that a problem st=
atement illuminates prospective solutions. In case you missed it, the path=
forward is for you to gain visibility into that plethora of unknowns, or s=
adly report to your client, as we do to you, that with nothing to go on you=
have nothing to offer.
Visibility involves things like logging. You do use logging, don't you?
As an extra benefit, the experience of using logs to diagnose a production =
issue will provide an object lesson into how useless most programmers are a=
t designing logging, and give you insight into proper logging practices.
--
Lew