wood burning stoves 2.0*
The moose likes I/O and Streams and the fly likes why does java.util.logging.logger create multiple files and locks for mutithreaded pr Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » I/O and Streams
Bookmark "why does java.util.logging.logger create multiple files and locks for mutithreaded pr" Watch "why does java.util.logging.logger create multiple files and locks for mutithreaded pr" New topic
Author

why does java.util.logging.logger create multiple files and locks for mutithreaded pr

h sangi
Greenhorn

Joined: Apr 28, 2003
Posts: 1
The code listed below uses Java's (jdk 1.4) logging utility. A new log file is created for each day and messages are appended to the file.
In a single thread the code works as per the above defined requirement. However in a multithreaded test case, the program does not create a single file. Messages from mutiple threads are written to multiple files. The behaviour is as listed.
Say there are 5 messages from five threads.
The logger creates five log files and five lock files. All five messages are posted to the first log. Four messages are posted to the second file. Three to the next and so on. The last file contains one message.
Any help in resolving the issue is appreciated.

[ April 28, 2003: Message edited by: Jim Yingst ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Ugh. I added [code] tags above to imporve readability, but the indentation is rather strange. It would really help if you made the indentation more consistent. Don't use tabs - they look different in various formats. Use spaces.
It's hard to tell for sure right now, but it seems the problem most likely is the first part of logProcessMessage(). Since there's no synchronization here, one thread may still be executing checkFileName(), createFileName(), or initialize(), when another thread comes along and tries checkFileName(). The second thread may find that checkFileName() returns false, because the first thread's initialize() has not completed. This will lead to the second thread running initialize() as well, and creating a new logger in response. This is probably how you're getting so many extra log files. To fix it, the simplest response is to put a synchronized (this) block around the first part of logProcessMessage(), to ensure that no other threads can start checkFileName() until the first thread has completed initialize().
You may also be able to redesign your code a bit. The checkFileName() method looks farily slow, for somethign that's going to be called each time you log something. Perhaps when you first create a logger you could also calculate the time (in milliseconds since 1/1/70) at which it will be necessary to change to another logger, and save that. Then when logProcessMessage() is called, just compare System.currentTimeMillis() to the saved time, and if the current time is less, that means your existing log file is still good. Otherwise, create close the old log file and start a new one. I expect the whole process can be much faster than it is now.


"I'm not back." - Bill Harding, Twister
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: why does java.util.logging.logger create multiple files and locks for mutithreaded pr