too many open files

Hi,

I have a test program that iterates through a directory of about 200 files, and opens them, processes them with a regex, and closes them, before moving on to the next one.

I then run this program in 10 threads simultaneously. The files are processed rather quickly. Actually I use a randomAccessFile as a temp file to reread chars already read, so that for each input stream, there is a FileInputStream open and a RandomAccessFile. But I close them iteratively.

When running with default memory arguments, everything works. But when I bump the memory to 500Meg with -Xmx500m argument, I start seeing IOException("too many open files") all over the place, even leading to NoClassDefFoundError because the ClassLoader can't even load my classes from the classes directory.

I've read somewhere that even when you explicitly call close, there may be some delay relative to GC finalization before the actual file descriptors are released to the OS. What's up with that!? By the way, I'm seeing this problem in 1.4 and 1.5, but haven't yet tried 1.6.

Any ideas?

Andy

[1112 byte] By [p7ea] at [2007-11-27 5:11:25]
# 1

Well, I found the cause of the problem. In all JREs, including 1.6 and the latest 1.5.0_11, InputStreamReader.close() method is supposed to and does close the underlying InputStream from which it was constructed. This is both verified in testing and in the documentation. So in my code, which obtained an InputStreamReader for the File, I was just calling InputStreamReader.close() on "close event".

Unfortunately, in all JREs, this underlying close is not "instantaneous" for some strange reason. If in my close event, I close BOTH the InputStreamReader and the InputStream explicitly, the problem goes away.

I think this is a bug in the JREs.

p7ea at 2007-7-12 10:31:47 > top of Java-index,Desktop,Runtime Environment...