When the controller start notification is sent, the Listener class handles the notification:

package sample.timer;
  
import javax.management.*;
  
public class Listener implements NotificationListener {
  public void handleNotification(Notification notification, Object obj) {
    String type = notification.getType(  );
    if (notification instanceof TimerNotification) {
      TimerNotification notif = (TimerNotification)notification;
      if (type.equals("sample.timer.controllerStart")) {
                       Properties props = (Properties)notif.getUserData(  );
        final String cwf = 
          (String)props.getProperty("controller.consumer.workFactor");
        final String swf = 
          (String)props.getProperty("controller.supplier.workFactor");
        Thread t = new Thread(new Runnable(  ) {
                         public void run(  ) {
                           Controller.main(new String[] {cwf, swf});
                         }
                       } );
                       t.start(  );
      }
    }
  }
}

The code for the Listener class is relatively simple, as it has to implement only the handleNotification( ) method of NotificationListener. Recall that when the timer service sends a notification, an instance of the TimerNotification class is emitted to all interested listeners. This is the only type of notification in which Listener is interested. If the notification is not of the right type (sample.timer.controllerStart), it is ignored. If the notification type string is of the correct type, the getUserData( ) method of the Notification class (TimerNotification’s parent class) is invoked to retrieve the Properties object we stored there when the controller start notification was added to the timer service. The Controller is started on a separate thread of execution, because Controller.main( ) does not terminate until all other threads in Controller (e.g., consumer and supplier threads) are finished. If we don’t start the Controller on its own thread from handleNotification( ), it may hang the timer service’s notification thread if we run the code on single-processor systems, and other notifications may not be sent by the timer service until Controller.main( ) is finished executing!

When the notification to flush queued messages to disk is sent by the timer service, the MessageLogQueue class handles it:

package sample.utility;
  
import javax.management.*;
public class MessageLogQueue extends MessageLog
  implements NotificationListener {
  // singleton stuff. . .
  private static MessageLogQueue _instance = null;
                 public static MessageLogQueue instance(  ) {
    if (_instance == null)
      _instance = new MessageLogQueue(  );
    return _instance;
  }
  
  private ArrayList _store = new ArrayList(10);
                 public synchronized void write(String message) {
    _store.add(message);
  }
  public synchronized void write(Throwable t) {
    _store.add(t);
  }
    
  public synchronized void handleNotification(Notification notification,
                                                             Object obj) {
                   if (notification instanceof TimerNotification) {
      String type = notification.getType(  );
      if (type.equals("sample.timer.flushlog")) {
        if (_store.size(  ) > 0) {
          Iterator iter = _store.iterator(  );
          while (iter.hasNext(  )) {
            Object message = iter.next(  );
            if (message instanceof String)
                             super.write((String)message);
                           else if (message instanceof Throwable)
                             super.write((Throwable)message);
          }
          _store.clear(  );
        }
      }
    }
  }
}

The emphasized lines in this code point out some of the features of the MessageLogQueue class. First, the class is implemented using the singleton pattern, so that there is only one instance of the class for the process (i.e., the JVM)—this allows all classes in the JVM to write their log messages to the log file in an asynchronous fashion. The backing store for the “queue” inside MessageLogQueue is an ArrayList, and access to the contents of the list must be synchronized.

As we saw earlier, if the Notification object that is sent is not a TimerNotification, it is simply ignored. This goes for the notification type as well, which must be sample.timer.flushlog. Any messages in the backing store for the queue are written out one at a time using an Iterator. Because both String and Throwable message types are allowed, the Java keyword instanceof is used to determine the type of the current entry in the list, so that it can be appropriately cast when delegating to the superclass’s write( ) method. Once the contents of the queue have been written to the log file, the backing store for the queue is emptied and is ready for the next batch of messages.