Question

I’m writing a webapp that basically allows users to kick off shell scripts with parameters they enter through various forms. After doing some research I believe ProcessBuilder to be the best way to run the shell scripts, however I’ve got some conditions that I need to meet and was hoping some others could tell me if I’m thinking along the correct lines.

The scripts that will be kicked off can literally take a few hours to run. So obviously I can’t have the app pause and wait for that long. So I’m wondering if threads is the answer to that problem? I’m not very experienced with using threads and looking for some advice. Should I kick off the ProcessBuilder in a new thread so that the main web app will continue to run? Will that even work? Is it as simple as just declaring a new thread and assigning the process builder to it? Do I have to worry about having various threads running or created? Just not sure of what to be on the look out for or what pitfalls to keep aware of.

Also, I really need a way to be able to at least check on the status of the process once it is running. The requirements call for some way to show how far along the process is, but I don’t know that that is possible. I believe being able to at the very least show that it is still running should be acceptable. How would I go about detecting that?

For some more info it’s a Java/Spring web app and will be running on some flavor of Unix. Thanks for any thoughts and help.

Answer 1

You could implement something like a JobManager and a Job.

A Job could be a Runnable which has a ProcessBuilder. In it’s run method, it starts the process (ProcessBuilder.start), waits for it to exit and calls back to the JobManager when finished, possibly returning the exit status of the process.

The JobManager creates Jobs (each in a new Thread), maintains a collection of current jobs (and maybe a collection of recently finished jobs, maybe a list of failed jobs). Clients can give the JobManager jobs to execute and query for the status (running, finished, failed) of all jobs or a particular job.

Regarding status of the process, the Job could have startTime, endTime and exitStatus variables and associated get methods. You could return these to the client to display a job status table.

Your Job.run method might look something like this.

public void run() {
  startTime = System.currentTimeMillis();  
  process = processBuilder.start();

  // spawn threads to consume process output streams
  // even if you're not going to read them

  while (running) {
    try {
      process.waitFor();
      running = false;
    } catch (InterruptedException e) {
      // you could stop a process by interrupting it's Job thread
      process.destroy();
    }
  }
  exitStatus = process.exitValue();
  endTime = System.currentTimeMillis();
  jobManager.onExit(this);
}

Regarding “% complete”, that’s only going to be possible if you have some way of measuring it.

If a task should complete within a certain time, you could use that as a rough way of reporting expected completion time / completion percentage.

Or maybe you could capture the output of the processes, using that to set a percentComplete variable in your Job. For example, when you see “message X” in the ouput, set percentComplete=25%. This would mean implementing custom code per type of script – maybe a Job subclass or give the Job a member variable responsible for parsing the output.