3

I am developing a simple swing application with a JTextArea to show log messages from the entire application. In order to develop this application, I am using a simplified version of the MVC pattern, in which the controller is interposed between the view and the model in both directions:

  • when the user interacts with a swing control, if this interaction requires access to the model (that is, it requires reading and/or writing the model), then the event raised by the swing control calls for an appropriate method of controller;
  • when the view should be updated, the controller invokes one or more methods of the view.

Almost all exceptions are caught in the controller and sent to the java.util.logging.Logger, as in the following code snippet.

public void onWriteFile() {
    try {
        // ...
    }
    catch(IOException ex) {
        Logger.getLogger(Controller.class.getName()).log(Level.SEVERE, "onWriteFile()", ex);
    }

    view.refresh(...);
}

Only the following exception is caught inside a custom graphical component and is sent to the logger (I took inspiration from the example in Listing 6. Robust listener invocation of Java theory and practice: Be a good (event) listener).

private synchronized void processDrawingEvent(DrawingEvent e) {
    if (e == null) {
        return;
    }

    for (Iterator<DrawingListener> i = listeners.iterator(); i.hasNext();) {
        DrawingListener listener = i.next();
        try {
            switch (e.getStatus()) {
                case DRAWING:
                    listener.drawing(e);
                    break;
                case DONE:
                    listener.done(e);
                    break;
                case DELETED:
                    listener.deleted(e);
                    break;
                }
        } catch (RuntimeException ex) {
            i.remove();
            Logger.getLogger(ImagePanel.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Currently all calls to the Logger.log(...) method are coming from the same thread. However, if this method was invoked by different threads, should I use a solution like this?

Community
  • 1
  • 1
enzom83
  • 8,080
  • 10
  • 68
  • 114
  • Look at Log4j2. It has a built in asynchronous logger – Isaiah van der Elst Aug 21 '15 at 23:48
  • 1
    The [Logger reference (JDK 7)](http://docs.oracle.com/javase/7/docs/api/java/util/logging/Logger.html) clearly states `All methods on Logger are multi-thread safe`. ++ You seem to be polling about the [an specific AsyncFileHandler implementation](http://stackoverflow.com/a/27409673/364056). I don't know if that is a proper question. ++ That answer seems to be adequate for IO-intensive logging (which might be independent from multi-threading). ++ I would say go for it (I'm not going to test it for you). – Javier Aug 21 '15 at 23:57
  • Your development looks like a Rich Client (Swing). I would not expect a high volume of logging from that. I would keep it simple and focus on actual issues. – Javier Aug 22 '15 at 00:07

1 Answers1

4

It depends on what problem you are trying to solve here.

From the perspective of code correctness, you don't need to do anything special to share the same Logger object across multiple threads. The class is thread-safe.

The Q&A you have linked to is solving a different problem; i.e. how to prevent logging I/O from being a performance bottleneck by decoupling logging from writing the log file.

If you are trying to avoid logging bottlenecks, then it is worthwile considering that kind of approach. However, in your case asynchronous handling of log messages has other probelms:

  • Since you are writing the log messages to the screen, if you make that asynchronous, the log messages that the user sees could lag behind what is actually going on. Indeed, if there are a lot of log events, the lag could be considerable. IMO, that would be undesirable.

  • If the log event rate is too high, then asynchronous handling is eventually going to "back up" and logging becomes a bottleneck.

  • Writing to a screen is going to be a lot more expensive than writing to a file. It involves a lot more CPU and I/O, both in Java and in the window manager and (ultimately) I/O devices that Java interacts with to get the pixels onto the screen. (For example, scrolling ...) That is going to mean that the you can sustain a much lower logging rate if you log to the screen rather than a file.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216