Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10528

Re: java.io.File

Show all headers | View raw

On Fri, 2 Dec 2011 14:02:05 -0800 (PST), Lew <lewbloch@gmail.com>
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).

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 09:35 +0000
  Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 07:25 -0800
    Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 15:55 +0000
      Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 08:17 -0800
        Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-02 16:31 +0000
          Re: java.io.File markspace <-@.> - 2011-12-02 08:53 -0800
          Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:02 -0800
            Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 17:12 -0500
              Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:16 -0800
                Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 18:42 -0500
                Re: java.io.File Lars Enderin <lars.enderin@telia.com> - 2011-12-03 01:06 +0100
                Re: java.io.File Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-12-07 15:51 +0200
            Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-05 15:14 +0000
              Re: java.io.File markspace <-@.> - 2011-12-05 07:49 -0800
                Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-05 16:28 +0000
              Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-05 15:25 -0800
                Re: java.io.File Mark <i@dontgetlotsofspamanymore.net> - 2011-12-06 10:29 +0000
          Re: java.io.File Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 17:08 -0500
      Re: java.io.File Roedy Green <see_website@mindprod.com.invalid> - 2011-12-03 00:57 -0800
    Re: java.io.File Mayeul <mayeul.marguet@free.fr> - 2011-12-02 17:33 +0100
      Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-02 14:07 -0800
        Re: java.io.File Mayeul <mayeul.marguet@free.fr> - 2011-12-06 15:52 +0100
          Re: java.io.File Lew <lewbloch@gmail.com> - 2011-12-06 09:23 -0800

csiph-web