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

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

Re: java.io.File

Show all headers | View raw

On Mon, 05 Dec 2011 07:49:52 -0800, markspace <-@.> wrote:

>On 12/5/2011 7:14 AM, Mark wrote:
>> 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?
>
>Well, the problem here is that not all objects are GC'd in their 
>lifetimes.  When the JVM shuts down, no objects are GC'd, the memory 
>they occupy is just released.  No finalizers are run.
>
>I've had this happen personally to me.  Forget to close a stream, and 
>when the program ends no data is written.  It's still buffered in the 
>JVM.  Close your streams and you get data on the disc, like you expected.

Which is why I would always explicitly release a resource as soon as
it is not needed, rather than rely on GC.

>> 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.
>
>The File object represents a path.  It's basically just a String. 
>Please stop bringing it up, it's got nothing to do with the issue of OS 
>resources.

I kept bringing it up because I had not had an answer -- until now.

>> On Fri, 2 Dec 2011 14:02:05 -0800 (PST), Lew<lewbloch@gmail.com>
>> wrote:
>>> '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.
>
>Are you sure you're calling close() in all cases?  It sounds like not, 
>perhaps you are, but that's the point being made here.

I can't be 100% sure since there is a lot of code but I have been
through it all and cannot find any.  I have seen similar problems to
this before and I have managed to find the culprit without too much
effort.  However one thing I am not clear about is which Java objects
/may/ use or retain OS resources - in this case file handles.

>>> Some people believe in Creationism.  It doesn't make their belief valid.
>>
>> Oh Boy.
>
>He's pointing out that despite references to methods and finalizers, it 
>doesn't look like they're being called properly.  We need better 
>evidence of what is actually happening to make a better diagnosis of the 
>problem.  Everything right now is just guesses and hunches.
>
>> 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).
>
>"Doing something" should be, imo, making a plan to gather more 
>information.  Where can you add logging that will prove, or disprove, 
>the current theories about what is happening with the program?

There's lots of things I have already done including adding extra
logging and requesting more information.  However, until I get a reply
to my requests, I don't feel it is appropriate for me to stop.

>I'm sure there's a unix command to dump resources (like file handles) 
>held by each process.  How about dump the out put of that into a file 
>before each shell command so we can see who is actually holding on to 
>those resources.

That is one of the things I have already asked for.

>Also think about increasing the amount of file handles allowed by the 
>JVM or other processes.  The default is actually pretty restrictive and 
>designing to stop "abusive" processes.  Really some processes need much 
>more.  Don't be afraid to increase it if needed.

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