new FileWriter hangs

Thread view:

mattias - 31 Jul 2005 06:01 GMT

Hello. I have a java program where I repeatedly write to a log file,
and at random times (typically after 100.000 writes or so) the program
just hangs. I've found that this happens while executing a 'new
FileWriter' command. I only have one thread writing to the file,
there's no exceptions thrown or anything, the CPU usage just goes to
zero and then nothing happens at all. Meanwhile, the log file remains
globally locked for writing, i.e. I can't delete it in Explorer without
first killing my java program. I experience this bug on a dual xeon
processor machine, running Windows Server 2003 and java version
1.5.0_04.

Here's the code, it hangs while executing the very first line of code:

FileWriter fileWriter = new FileWriter("log.txt", true);
BufferedWriter buffWriter = new BufferedWriter(fileWriter);
buffWriter.write(message);
buffWriter.newLine();
buffWriter.close();

If anyone has any ideas why this happens, please let me know. I guess
in this case I could leave the file open at all times to avoid this,
but I would be more interested to know the cause of it.

Mattias

Reply to this Message

HGA03630@nifty.ne.jp - 31 Jul 2005 08:07 GMT

> Hello. I have a java program where I repeatedly write to a log file,
> and at random times (typically after 100.000 writes or so) the program
[quoted text clipped - 20 lines]
>
> Mattias

Reply to this Message

jan V - 31 Jul 2005 09:52 GMT

> If anyone has any ideas why this happens, please let me know. I guess
> in this case I could leave the file open at all times to avoid this,
> but I would be more interested to know the cause of it.

Sounds like a deadlock doesn't it? Have you pressed the magic keys to
provide a dump of the JVM's state (which includes deadlock info) ?

.. from the Java docs:

"A deadlock detection utility has been added to the Java HotSpot VM. The
utility is invoked by a Ctrl+\ on the command line while an application is
running. The utility detects Java-platform-level deadlocks, including
locking done from the Java Native Interface (JNI), the Java Virtual Machine
Profiler Interface (JVMPI), and Java Virtual Machine Debug Interface
(JVMDI).

When invoked, the utility displays a thread dump to standard out and
indicates any Java-platform-level deadlocks it detects. Refer to this sample
output. If the application is deadlocked because two or more threads are
involved in a cylce to acquire monitors, then the list of such threads and
monitors involved in the deadlocks are displayed. Note, however, that this
will not find deadlocks involving threads waiting on monitors on which no
signal will be forthcoming. "

Reply to this Message

Thomas Hawtin - 31 Jul 2005 16:19 GMT

> Here's the code, it hangs while executing the very first line of code:
>
[quoted text clipped - 3 lines]
> buffWriter.newLine();
> buffWriter.close();

As jan says, looks like a dead lock. However the code isn't safe as you
don't guarantee to close the FileWriter. It should look something like:

FileWriter fileWriter = new FileWriter("log.txt", true);
try {
BufferedWriter buffWriter = new BufferedWriter(fileWriter);
buffWriter.write(message);
buffWriter.newLine();
buffWriter.close();
} finally {
fileWriter.close();
}

In any case opening and closing a file that fast doesn't seem like a
good idea. It's heavy on operating system resources and also on
finalisers. If multiple processes do need to access the single file,
then you are quite likely to have lots of exceptions as they collide.

If it is true that multiple processes need to access the file, perhaps a
better route is to use RandomAccessFile. From that you can get the
java.nio.channels.FileChannel which allows locking and unlocking
exclusive access to the file without opening and closing. I must admit
that I have not tried that myself.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

Roedy Green - 01 Aug 2005 03:21 GMT

>If it is true that multiple processes need to access the file, perhaps a
>better route is to use RandomAccessFile.

He is just tacking on the end.

Just write a synchronised method to write one log entry, and leave the
file open, or use the autoflush if you are concerned about losing the
tail on a crash.

Signature

Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

Reply to this Message

Thomas Hawtin - 01 Aug 2005 03:43 GMT

>>If it is true that multiple processes need to access the file, perhaps a
>>better route is to use RandomAccessFile.
[quoted text clipped - 4 lines]
> file open, or use the autoflush if you are concerned about losing the
> tail on a crash.

The reason I suggested RandomAccessFile was for the case where there are
more than one process appending to the same file. If you try that with
FileWriter/FileOutputStream kept open, you will rapidly run out of luck.
Perhaps just viewing the file causes problems.

OTOH, if it is just from the same process (and accessible) then,
absolutely, a long lived FileWriter/OutputStreamWriter(FileOutputStream)
is the way to go.

Tom Hawtin

Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Reply to this Message

new FileWriter hangs

Free Magazines