What's the best way to release resources after java.util.Timer?

Question

I have an AutoCloseable whose close() method is being called prematurely. The AutoCloseable is ProcessQueues below. I don't want the close() method to be called when it is currently being called. I'm considering the removal of "implements AutoCloseable" to accomplish that. But then how do I know when to call ProcessQueues.close()?

 public class ProcessQueues implements AutoCloseable {
    private ArrayList<MessageQueue> queueObjects    = new ArrayList<MessageQueue>();

    public ProcessQueues() {
        queueObjects.add(new FFE_DPVALID_TO_SSP_EXCEPTION());
        queueObjects.add(new FFE_DPVALID_TO_SSP_ESBEXCEPTION());
        ...
    }
    
    private void scheduleProcessRuns() {
        try {
            for (MessageQueue obj : queueObjects) {
                monitorTimer.schedule(obj, new Date(), 1); // NOT THE ACTUAL ARGUMENTS
            }
        }
        catch (Exception ex) {
           // NOT THE ACTUAL EXCEPTION HANDLER
        }
    }

    public static void main(String[] args) {   
      try (ProcessQueues pq = new ProcessQueues()) {
        pq.scheduleProcessRuns();
      } catch (Exception e) {
         // NOT THE ACTUAL EXCEPTION HANDLER
      }
    }

    @Override
    public void close() throws Exception {
      for (MessageQueue queue : queueObjects) {
        queue.close();
      }
    }
}

I want ProcessQueues.close() to be called, but not until the task execution threads of all Timer objects terminate. As written, ProcessQueues.close() will be called as soon as the tasks are scheduled. I can easily solve that by removing "implements AutoCloseable" from the ProcessQueues class (and removing the @Override annotation). But then I have to call ProcessQueues.close() myself. How do I know when the task execution threads of all Timer objects have terminated? That's when I want to call ProcessQueues.close().

Note that MessageQueue isn't instantiated in the resource specification header of a try-with-resources block, so although MessageQueue also implements AutoCloseable, the feature isn't utilized here. I'm explicitly calling MessageQueue.close(). It is in MessageQueue.close() that I release resources. Releasing those resources prematurely causes the task execution threads to fail to complete their tasks.

I'm considering an explicit call to ProcessQueues.close() after rewriting the code to prevent automatic resource deallocation, but again I don't know how to discover the right time for that explicit call.

I considered overriding ProcessQueues.finalize(), but "Java: How to Program", Eleventh Edition advises against that. "You should never use method finalize, because it can cause many problems and there's uncertainty as to whether it will ever get called before a program terminates... Now it's considered better practice for any class that uses system resources... to provide a method that programmers can call to release resources when they're no longer needed in a program." I have such a method. It's ProcessQueues.close(). But when should I call it?

Answer 1

I could terminate the Timer, but having it run perpetually is intentional. The question is in consideration of what happens when something else terminates the Timer and the MessageQueue objects are no longer needed. It is at that point that I would like to call ProcessQueues.close().

If I were to use the Executor framework, rather than Timer, then I could use ExecutorService.awaitTermination(long timeout, TimeUnit unit)

TimerTask is a Runnable, and MessageQueue is already a TimerTask, so MessageQueue need not change.

'ExecutorService.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS)' would effectively wait forever for termination.

  public static void main(String[] args) {   
  try (ProcessQueues pq = new ProcessQueues()) {
    pq.scheduleProcessRuns();

    // Don't take this literally.
    ExecutorService.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);

  } catch (Exception e) {
     // NOT THE ACTUAL EXCEPTION HANDLER
  }
}

Of course, awaitTermination isn't a static method, so I'll have to have an ExecutorService, but you get the idea.

After termination, the AutoCloseable feature is leveraged and ProcessQueues.close() is implicitly called.

All that remains is to start the threads for perpetually repeated calls to each TimerTask, using the Executor framework. The answer to that question is ScheduledExecutorService.

I think this will work.

Answer 2

You have conflicting lifecycle issues here.

You have Timer whose lifecycle is 100% in your control. You start it, you stop it, and that's it. But you have no direct introspection in to the status of the threads being managed by the Timer. So, you can't ask it if it has anything currently running, for example.

Then you have your MessageQueue, which is invoked by the Timer. This is the lifecycle you're interested in. You want to wait for all of the MessageQueues to be "done", for assorted values of done. But, since the queue are constantly being rescheduled (given the Timer.schedule method that you're using), they're NEVER "done". They process their contents and go off and run again.

So, how is anyone to know when "done" means "done"?

Is it up to the MessageQueue? Or is it up to the ProcessQueues? Who's in command here?

Notice, nothing ever cancels the Timer. It's just runs on and on and on.

So, how can one know when MessageQueue can be closed?

If MessageQueue is the real driver here, then you should add lifecycle methods to the MessageQueue that ProcessQueues can monitor to know when to shut things down. For example, you could create a CountDownLatch set for however many MessageQueues are in your list, and then subscribe to a new lifecycle method on the MessageQueue that it calls when it's finished. The callback method can then decrement the CountDownLatch, and the ProcessQueues.close method simply waits on the latch to countdown before closing everything.

public class ProcessQueues implements AutoCloseable, MessageQueueListener {

    private ArrayList<MessageQueue> queueObjects = new ArrayList<MessageQueue>();
    CountDownLatch latch;

    public ProcessQueues() {
        queueObjects.add(new FFE_DPVALID_TO_SSP_EXCEPTION());
        queueObjects.add(new FFE_DPVALID_TO_SSP_ESBEXCEPTION());
        ... 
        queueObjects.forEach((mq) -> {
            mq.setListener(this);
        });
        latch = new CountDownLatch(queueObjects.size());
    }

    private void scheduleProcessRuns() {
        try {
            for (MessageQueue obj : queueObjects) {
                monitorTimer.schedule(obj, new Date(), 1); // NOT THE ACTUAL ARGUMENTS
            }
        } catch (Exception ex) {
            // NOT THE ACTUAL EXCEPTION HANDLER
        }
    }

    public static void main(String[] args) {
        try (ProcessQueues pq = new ProcessQueues()) {
            pq.scheduleProcessRuns();
        } catch (Exception e) {
            // NOT THE ACTUAL EXCEPTION HANDLER
        }
    }

    @Override
    public void close() throws Exception {
        latch.await();
        for (MessageQueue queue : queueObjects) {
            queue.close();
        }
        monitorTimer.cancel();
    }

    @Override
    public void messageQueueDone() {
        latch.countDown();
    }
}

public interface MessageQueueListener {    
    public void messageQueueDone();
}

public class MessageQueue extends TimerTask {
    MessageQueueListener listener;
    
    public void setListener(MessageQueueListener listener) {
        this.listener = listener;
    }
    
    private boolean isMessageQueueReallyDone {
        ...
    }
    public void run() {
        ...
        if (isMessageQueueReallyDone() && listener != null) {
            listener.messageQueueDone();
        }
    }
}

Mind, this means that your try-with-resource block will block waiting on all of the MessageQueues, if that's what you want, then you're good to go.

It also crassly assumes that your MessageQueue.run() knows when to shut down, which goes back to that "who's in control here" thing.