Question

My problem is: I have a class which accepts files in a directory. Whenever the first object arrives it starts some timer to perform a compress on all the files in a directory which arrive during the next 60 seconds.

This raises two requirements:

1) I need to be able to check if the “countdown” is already running when a new file arrives. I don’t want file2 to arrive 15 seconds after file1, then they get compressed together 45 seconds later only to have a second scheduled task fire 15 seconds after the first completed (to an empty directory).

2) Smart batching / non-constant polling. For example, if file1 arrives at time=0 and file2 arrives at time=59s, they would be compressed together. However, if file3 doesn’t arrive until time=89s, and file4 arrives at time=129s, I want to make sure the next “compress” operation is not happening at timer=120s, but rather at timer=149s (60 seconds after file3 arrived).

In other words: only one timer/countdown should ever be running. If it’s the first file since a compression, it should trigger a new one, but otherwise it should just be ignored.

I’m looking into java.util.Timer and Java.util.concurent.ScheduledExecutorService as solutions, but both seem built for having multiple processes, which I am trying to avoid.

Is there any better solution for this?

Answer 1

Here is an example code:

private Thread countDownThread;

public synchronized void onNewFile() {
    startCountDownThreadIfNotYetRunning();
}

public synchronized void resetThread() {
    if(uncompressedFilesExist()) {
        startCountDownThreadIfNotYetRunning();
    }
}

public synchronized void startCountDownThreadIfNotYetRunning() {
    if(countDownThread == null) {
        new Thread(new CompressionTask()).start();
    }
}

private class CompressionTask implements Runnable {
    @Override
    public void run() {
        try {
            Thread.sleep(60 * DateUtils.MILLIS_PER_SECOND);
            compressDirectoryContents();
            resetThread();
        }
        catch (InterruptedException e) { }
    }
}

1. When onNewFile() is called it tries to start a new countDownThread if it is not already running.

2. This thread waits for 60 seconds and starts compression.

3. The last step resetThread() is a bit tricky. If we simply call:

   countDownThread = null;
   

   the code would not be thread-safe. First of all change made to countDownThread might not be visible by other threads. Moreover if new file appears between compressDirectoryContents() and simple assignment, it would get lost. That’s why all operations are synchronized using the same lock.

   Because both onNewFile() and resetThread() are guarded by the same lock, it is not possible that new file appears but the count-down thread is not started.

Note that you don’t need any fancy Timers or ScheduleExecutorService – creating a single thread every minute isn’t an overkill.