0

We have a homegrown utility for integrating between products that uses java.util.logging. We have an XML config file that the utility reads in and programmatically sets the logging at startup (the xml has other configurations for the utility, also). While running, if a user changes the logging level, a WatchService detects it and sets the level. Here's the code that does the logging:

        Level level = Level.parse(logConfig.getLogOutput().getLogOutputLevel());
        if(!isLoggingInitialized)
        {
                int maxSize = fileLog.getMaxFileSize() * 1000000;
                Logger maneClient = Logger.getLogger("com.raytheon.mane.client");

                String path = fileLog.getLogFileOutputPath();
                File f = new File(path);
                if(!Files.exists(f.toPath().getParent()))
                {
                    try
                    {
                        Files.createDirectories(f.toPath().getParent());
                    }
                    catch(IOException ioe)
                    {
                        throw new MANEClientException("Unable to create logging directory: " + ioe.getMessage(), ioe);
                    }
                }
                FileHandler fileHander = new FileHandler(fileLog.getLogFileOutputPath(), maxSize, fileLog.getMaxBackupIndex().intValue(), true);
                fileHander.setFormatter(new SimpleFormatter());
                fileHander.setLevel(level);
                maneClient.addHandler(fileHander);
                maneClient.setUseParentHandlers(false);

                isLoggingInitialized = true;
        }
        else
        {
                Logger maneClient = Logger.getLogger("com.raytheon.mane.client");
                Arrays.asList(maneClient.getHandlers()).forEach(h -> h.setLevel(level));
        }

(we use JAXB which I didn't include the parsing of those objects)

In our development environment, this logging works as expected. If I start the app with Level.OFF, the log file is created (including the .lck) but nothing is written. Once I change the xml config to FINE, I get the expected logging. So that's great.

However, in our test lab, if I set Level.OFF and then later change it, no logging occurs until we stop the service running the app, at which point it seems like all the logging that should have happened is flushed to the file.
If I start the app with Level.FINE, it logs, then swap to Level.OFF, logging stops, but if I switch back to Level.FINE or Level.INFO, no logging occurs until the service is stopped.

The only difference between environments that I can see is OS. The development environment is running on Open JDK 11 with Win 7 Prof. The server in the test environment is running Open JDK 11 with Win Server 8 (yes, I know. We're upgrading this year).

Is there a better way I should be doing this? Since it seems to work perfectly fine in one environment, I'm thinking the approach is fine.

Thanks!

Cthulhujr
  • 359
  • 3
  • 12

1 Answers1

0

If I start the app with Level.OFF, the log file is created (including the .lck) but nothing is written.

The .lck and the log file are created when the FileHandler is constructed. If you don't want those files then don't create the FileHandler when the level is OFF.

If I start the app with Level.FINE, it logs, then swap to Level.OFF, logging stops, but if I switch back to Level.FINE or Level.INFO, no logging occurs until the service is stopped.

Make sure you have a strong reference to the "com.raytheon.mane.client" logger. In your code you only use method local references. You need at least one static final reference to that logger to prevent garbage collection.

Also Windows will delay writing bytes to the disk (sync vs. flush). The behavior you describe would match FileHandler.close is performing the sync on shutdown. Currently the only way to make FileHandler perform a sync is to close it or make it rotate. Perhaps you just haven't written enough data to the log to make windows sync with the disk?

jmehrens
  • 10,580
  • 1
  • 38
  • 47
  • Thanks for the response, I'll give the static references a try, though I'm thinking your last suggestion might be the root since everything behaves nicely on a version of Windows prior to 2008. I'll let you know how it goes! – Cthulhujr Mar 04 '19 at 18:15