Sequential Jobs

Following this post about RCP application progress report  we have the following use case:

  1. User Action
  2. Start first Job (unknown length)
  3. Wait for first Job to finish and start second Job (known length)
  4. Wait for second Job to finish and start third Job (known length)

We want to show this to the user in the following way:

  1. Have a main “User Action” dialog without global progress bar (because of the 1st job length is unknown and really variable upon executions length I can’t get an accurate total length) or with an “unknown” length
  2. In this dialog have 3 sub parts one for each job with one progress bar for each one of this jobs and off course with IProgressMonitor.UNKNOWN style for the first job.
  3. In this dialog the progress bars will be updated sequentially as the underlying jobs.

This will allow the end user to immediately see that its action is divided into 3 sub-tasks (the sub-tasks are meaningful for end users) and each time a new sub-task is started he can see the length of this sub-task (unknown for the first).

After many searches we were not able to implement that using the Eclipse Job API,  and today we are reporting these 3 sub-tasks as 3 individual successive dialogs with the drawback that the end user may initially thinks that his action will be completed at the end of the first unknown sub-task.

How does the Eclipse workbench’s team and YOU handle such situations ?


15 thoughts on “Sequential Jobs

  1. A possible solution could be to schedule all 3 jobs at the same time and set ISchedulingRules to the jobs to guarantee the sequential processing. In the progress-dialog you would see then:

    Job1 – Doing some work…
    Job2 (Waiting)
    Job3 (Waiting)

  2. Thanks for the answer Tom. I just tried this solution but have an issue with it. The job are scheduled sequentially without problem but once the first one is finished the associated dialog showing the 2 other ones as waiting is closed. I thin kthis is related to the setUser(true) I called only on the first job. But trying to call this on the 3 jobs results in having threee dialogs opened at scheduling time … Have you got any idea about this ?

  3. Hi Manuel,

    I’ve done something similar recently.
    I implemented that with 4 jobs:
    I’ve a “master” job with a progress bar 0-100
    The master job just launches the 3 other jobs, and regularly update it’s own progress, based on the progress of the three sub-jobs.


  4. “My problem is that I don’t know the % of the total time of the first job. It can range from 5% to 80%, thus I can’t implement your solution.”

    Just pretend that is fixed. Take a number say 40%, and assume the first operation takes that much, no matter what happens. By the end of the first job, the progress will show it’s 40% done, and the user will now know that step 2 & 3 will take the remaining 60%.

    Reporting progress like this doesn’t have to be pixel precise. Just give an approximation to let the user know it’s working “somehow”.

    I’ve never heard someone complaining “the software said it’s going to be done in 53 seconds but in fact the software took 54 seconds! The software is LYING 1000 whole milliseconds to me!!!!”

    • Hi Hendy,

      Thanks for your answer.

      Unfortunately as answered to Xavier I can’t do that because my unkwnon job’s length ranges from 5% to 80% of the total time. Because this total time can be several minutes up to 15mn this can result in a software LYING about few minutes !!!

      • I hope you’re really not saying that your user complains if the software is (even) a few minutes off.

        If so, I’m afraid it means you need to fix your user instead of fixing the software.

        Seriously, this isn’t NASA launch countdown timer. Or that a bomb explodes if your software miscounts, even by a few minutes.

        A concrete case in point: try to download a 4 GB file from the Internet. Then gauge how % accurate is the downloader estimates your download time? The result would be far much worse than your software.

      • You are right it’s not NASA launch countdown timer. And you are also right about the inaccuracy of the downloaders: I hate, from a user perspective, these gauge or the windows progress bar minutes that are sometimes seconds or hours. That’s why I am looking for a better solution, from a developer perspective, for my users.

      • Note that my views do not in anyway validate Eclipse Jobs API’s weakness on this issue. I highly support if anyone would improve Eclipse Jobs to handle this (I would say quite common) case of mixed unknown-time and known-time submonitors.

        I also appreciate Manuel’s decision wanting to fix this for the sake of users. That’s a very nice gesture and highly respectable.

        What I’d like to express is more from a project management standpoint (of Manuel’s specific case) rather than a technical one. (technically, the workaround to Jobs API’s weakness would be as Xavier described)

        If I were the project manager, I definitely want my valuable engineer’s time (which would be Manuel’s time) be optimally spent on more challenging and exciting problems, and deferring issues like the progress reporting on a functionality that can be off a few minutes. That and to educate users that some minor annoyances of software should be acceptable, and to do that is by showing the greatest features of the software (which Manuel develops). Now I guess that’d be what makes a developer really proud of, to develop the *primary* features that kick ass…!

      • The problem lies not with a deficiency in the Eclipse Jobs API, but rather with the unknown process length. If the program does not know how long the overall process will take, how can it hope to tell the user what the percentage complete is. Eclipse allows for this with the Indeterminate progress monitor.

        If you really to provide accurate feedback to the user, then you need to compute or estimate ahead of time what the total operation time will be. The units of this computation do not need to be seconds, often I will use something like the total number of records to be processed. The more accurate the estimation, the more accurate the progress to the user. There are tradeoffs, however. You don’t want your program to spend too much time computing an estimate just to provide the user accurate feedback.

        If there is truly no way of estimating whether your process will take 5% or 80% in a reasonable time, then the best you can do is to pick some fixed value as your estimate. Hendy recommended 40%, which is about halfway between. Another value may be more appropriate depending on how long your job takes on average.

  5. You may try to dig into the Eclipse update ui code which has an interface like this. I’m not sure how they do it, but the progress dialog pops up with a master progress and you can expand to see the individual download progress of files. Just try installing some new software and you can see what I mean. I don’t know exactly which project it comes from, probably p2.

  6. Pingback: Sequential Jobs | Eclipse | Syngu

  7. Pingback: Resume

  8. Pingback: Blog bookmarks 09/27/2011 « My Diigo bookmarks

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s