How to pass a message from TimerTask to main thread?

Question

I have a main client which keeps background timers for each peer. These timers run in a background thread, and in 30s (the timeout period) are scheduled to perform the task of marking the respective peer as offline. The block of code to do this is:

  public void startTimer() {
    timer = new Timer();
    timer.schedule(new TimerTask() {
      public void run() {
        status = false;
        System.out.println("Setting " + address.toString() + " status to offline");
        // need to send failure message somehow
        thread.sendMessage();
      }
    }, 5*1000);
  }

Then, in the main program, I need some way to detect when the above timer task has been run, so that the main client can then send a failure message to all other peers, something like:

while (true)
  if (msgFromThreadReceived)
     notifyPeers();

How would I be able to accomplish this with TimerTask? As I understand, the timer is running in a separate thread, and I want to somehow pass a message to the main thread to notify the main thread that the task has been run.

Answer 1

I would have the class that handles the timers for the peers take a concurrent queue and place a message in the queue when the peer goes offline. Then the "main" thread can poll the queue(s) in an event-driven way, receiving and processing the messages.

Please note that this "main" thread MUST NOT be the event dispatch thread of a GUI framework. If there is something that needs to be updated in the GUI when the main thread receives the message, it can invoke another piece of code on the event dispatch thread upon reception of the message.

Two good choices for the queue would be ConcurrentLinkedQueue if the queue should be unbounded (the timer threads can put any number of messages in the queue before the main thread picks them up), or LinkedBlockingQueue if there should be a limit on the size of the queue, and if it gets too large, the timer threads have to wait before they can put another message on it (this is called backpressure, and can be important in distributed, concurrent systems, but may not be relevant in your case).

The idea here is to implement a version of the Actor Model (q.v.), in which nothing is shared between threads (actors), and any data that needs to be sent (which should be immutable) is passed between them. Each actor has an inbox in which it can receive messages and it acts upon them. Only, your timer threads probably don't need inboxes, if they take all their data as parameters to the constructor and don't need to receive any messages from the main thread after they're started.

public record PeerDownMessage(String peerName, int errorCode) {
}

public class PeerWatcher {
    private final Peer peer;
    private final BlockingQueue<PeerDownMessage> queue;

    public PeerWatcher(Peer peer, BlockingQueue<PeerDownMessage> queue) {
        this.peer = Objects.requireNonNull(peer);
        this.queue = Objects.requireNonNull(queue);
    }

    public void startTimer() {
        // . . .
            // time to send failure message
            queue.put(new PeerDownMessage(peer.getName(), error));            
        // . . .
    }
}

public class Main {
    public void eventLoop(List<Peer> peers) {
        LinkedBlockingQueue<PeerDownMessage> inbox =
            new LinkedBlockingQueue<>();
        for (Peer peer : peers) {
            PeerWatcher watcher = new PeerWatcher(peer, inbox);
            watcher.startTimer();
        }
   
        while (true) {
            PeerDownMessage message = inbox.take();
            SwingWorker.invokeLater(() {
                // suppose there is a map of labels for each peer
                JLabel label = labels.get(message.peerName());
                label.setText(message.peerName() +
                    " failed with error " + message.errorCode());
            });
        }
    }    
}

Notice that to update the GUI, we cause that action to be performed on yet another thread, the Swing Event Dispatch Thread, which must be different from our main thread.

There are big, complex frameworks you can use to implement the actor model, but the heart of it is this: nothing is shared between threads, so you never need to synchronize or make anything volatile, anything an actor needs it either receives as a parameter to its constructor or via its inbox (in this example, only the main thread has an inbox since the worker threads don't need to receive anything once they are started), and it is best to make everything immutable. I used a record instead of a class for the message, but you could use a regular class. Just make the fields final, set them in the constructor, and guarantee they can't be null, as in the PeerWatcher class.

I said the main thread can poll the "queue(s)," implying there could be more than one, but in this case they all send the same type of message, and they identify which peer the message is for in the message body. So I just gave every watcher a reference to the same inbox for the main thread. That's probably best. An actor should just have one inbox; if it needs to do multiple things, it should probably be multiple actors (that's the Erlang way, and that's where I've taken the inspiration for this from).

But if you really needed to have multiple queues, main could poll them like so:

while (true) {
    for (LinkedBlockingQueue<PeerDownMessage> queue : queues) {
        if (queue.peek() != null) {
            PeerDownMessage message = queue.take();
            handleMessageHowever(message);
        }
    }
}

But that's a lot of extra stuff you don't need. Stick to one inbox queue per actor, and then polling the inbox for messages to process is simple.

I initially wrote this to use ConcurrentLinkedQueue but I used put and take which are methods of BlockingQueue. I just changed it to use LinkedBlockingQueue but if you prefer ConcurrentLinkedQueue, you can use add and poll but on further consideration, I would really recommend BlockingQueue for the simplicity of its take() method; it lets you easily block while waiting for the next available item instead of busy waiting.