Remoting and long running processes

[aaime]

I have a use case where a client can initiate, thru a remote call, a long running process on the server. By long running, I mean something that can run for a few minutes (up to a couple of hours).

The user must be able to start the process, track its progress, cancel it if necessary.

It seems to me that the only way to get this is to make the client poll the server at uniform intervals, and spawn a separate thread on the server to perform the long running task. In the beginning I was thinking that the server should have sent back to the client "events" as in a classic "Observer" pattern, but it seems to be more trouble than it's worth.

Does anyone of you have some experience on such a use case? Any consideration, comment is appreciated.

[jcej]

Instead of spawning a separate thread on the server I would suggest a thread pool. There is a JSR 166 backport (http://www.mathcs.emory.edu/dcl/util...il-concurrent/) if you can't upgrade to a 1.5 JVM.

The Observer is a bit more work. Polling is probably the simplest to implement and I would certainly do that first to get the app working.

If your client is a long-running process (e.g. - a webapp) you might consider letting it export a remote service of its own. Then, when it submits the request it could provide a 'return address' for progress updates and such.

[aaime]

Instead of spawning a separate thread on the server I would suggest a thread pool. There is a JSR 166 backport (http://www.mathcs.emory.edu/dcl/util...il-concurrent/) if you can't upgrade to a 1.5 JVM.

Nice, I'll have a look at it.

The Observer is a bit more work. Polling is probably the simplest to implement and I would certainly do that first to get the app working.

If your client is a long-running process (e.g. - a webapp) you might consider letting it export a remote service of its own. Then, when it submits the request it could provide a 'return address' for progress updates and such.

Unfortunately it's a rich client that could be behind some NAT or firewall, so I simply can't use this solution... I would need something like a persistent connection initiated by the client, but apparently there is no support for this approach in Spring remoting.

[gmatthews]

Can you have the remote client write an entry to the db, which is polled by a something that can start Quartz jobs?

That way, you don't have to write your own job scheduling/handling system.

[aaime]

Can you have the remote client write an entry to the db, which is polled by a something that can start Quartz jobs?

That way, you don't have to write your own job scheduling/handling system.

Hum... the client will have a progress bar and a cancel button, this means that the long running process must start right away and be controllable. I would have to poll the database each 0.5/1 seconds and then, how do I interact with the Quartz job?
You see, it's not really scheduling, it's an interactive long running process. When it ends, I have to show the user a report. In one case, I have to wait for an intermediate result, have the user confirm it, and start the second part of the long running process (possibily without removing what I have done so far from the main memory).

[gmatthews]

Can you elaborate on exactly what your long running process is?

[aaime]

Can you elaborate on exactly what your long running process is?

Metereological data validation and analysis. The data rows under analysis may be hundred of thousands. Usually the process is scheduled, but the user may request interactive runs in order to test new validation and configuration parameters, or to invalidate a scheduled run that did not get proper results.

[oliverhutchison]

I've implemented a similar requirement as follows. On the server we present a simple facade with an interface like this:

interface LongRunningJobManager {
      JobKey start(JobDefinition jobDefinition);
      JobStatus getStatus(JobKey jobKey);
      void cancel(JobKey jobKey);
}

behind this facade is a thread pool for running the jobs and a map from JobKey to status+executing thread of each active job. On the client we adapt this (convenient for remoting but not for the client) interface to the following:

interface LongRunningJob {
      JobDefinition getDefinition();
      void start();
      void cancel();
      void addJobEventListener(JobEventListener listener);
}

interface JobEventListener {
      void jobStarted(LongRunningJob job);
      void jobCompletedSomeWork(LongRunningJob job, JobStatus status);
      void jobCancelled(LongRunningJob job);
      void jobFinished(LongRunningJob job, JobResult result);
}

The implementation of LongRunningJob simply pools the server interface at some useful interval (to cut down on remote invocations we use an adaptive interval that is based on the rate the job is progressing) and if you're using Swing remember to fire the JobEventListener methods in the event dispatch thread!

HTH

Ollie

[aaime]

Oliver, that's more or less what I have here now (I've started developing it yesterday).
Yet, the adaptive polling is a nice touch I didn't thought about.
Willing to share some more details? ;-)

[oliverhutchison]

The jobs in our system progress at a reasonably predicable rate so initially we poll quite frequently but once we've received enough status info to roughly guess when the job will be complete we slow down the polling considerably. To keep the user happy we also spawn a thread that updates a status bar every 250ms based on an estimate of the actual progress - it's important that something is hapening on the screen to indicate that the job is actualy progressing.

Ollie