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

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

Re: java.io.File

Show all headers | View raw

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' 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.

'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 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.

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.

> 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.

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.

-- 
Lew

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

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