Comments on: Defining a background Job to run periodically

By: Robert Konigsberg

Robert Konigsberg — Tue, 03 Mar 2009 15:10:08 +0000

I sent Min’s comment about IStartup to some colleagues and here was a reply:
—
The point is that enabling your module to run it early during startup
will also enable all its dependencies and it does not scale well. The
push is to make everything turned on on demand. A couple of (3rd
party) plugins with their IStartups may effectively ruin the effort to
make the product lazily initialized.

This comment does not bring any convincing argument. If UI is displayed but there is a couple of threads running on background it is likely that the application will be unresponsive (thread priorities do
not help much).

By: Matthias

Matthias — Mon, 02 Mar 2009 11:37:01 +0000

Hi!

I like the idea of using a bundle’s lifecycle methods start() and stop() for starting and stopping a “job” controlled by some other bundle.
But a bundle can only be started once in a time. So if I have the use case that a job can be run any number of times this solution won’t work, because a bundle can only be started once until it is stopped, right?!

Which possibilities would I have for such an use-case?!?

By: Min Idzelis

Min Idzelis — Sun, 01 Mar 2009 19:18:22 +0000

Implementing IStartup no longer slows down IDE startup. In fact, the workbench is visible before the IStartups begin to run. In fact, the IStartups are actually run within a Job. (Jobs do not run until after the workbench has been restored. The JobManager is suspended until that time)

If you scheduled your job within your Plugin.start() method, it will only run when your plugin is activated. This can be far too late in some cases (depending on what your background job does.) That is why the IStartup extension point exists. One caveat on IStartup. Your IStartup extension is *not* guaranteed to run, because the user could have disabled it in the preferences. So you should take care that proper functioning of your plugin is not dependent on that IStartup extension.

Last note. You do not need a IJobChangedListener for periodic rescheduling. You can just call “schedule()” from within your job. This will cause your job to automatically reschedule itself after it runs.

However, if a user “cancels” the sleeping job, you will not get a chance to run (or to reschedule) yourself. In that case, you would still need a IJobChangedListener.

By: Jens Goldhammer

Jens Goldhammer — Sun, 01 Mar 2009 19:12:51 +0000

To reschedule the job, it is possible to do that in the run-method.

@Override
protected IStatus run(IProgressMonitor monitor) {
try{
// Work to do in the background
}
finally{
this.schedule(delay);
}

return Status.OK_STATUS;
}

So in my eyes, you don´t need the jobchangelistener…

By: Radoslaw Urbas

Radoslaw Urbas — Sun, 01 Mar 2009 18:56:47 +0000

@Robert – basically I was looking for Eclipse way of running some background task periodically.
All concerns regarding startup time are extremely important, but if the requirement is to do something at startup (or pretty close to startup) I don’t see the obvious effective solution for this. The suggestion regarding making the plug-in defining the job as tiny (including declared dependencies – direct ones and transitive) as possible to minimize the delay is good one. There is still one open question for me: what’s the advantage or disadvantage of using org.eclipse.ui.startup extension comparing to defining non-lazy bundle?

By: Robert Konigsberg

Robert Konigsberg — Sun, 01 Mar 2009 18:30:14 +0000

@Radoslaw, @Antoine’s suggestion is a good one. One wrinkle to consider: if starting your plug-in incurs a long time cost either because it has to start other bundles (that take a long time to start) or because it loads a lot of information, consider splitting your job’s plug-in from the rest of your plug-in.

My concern is that making your plug-in non-lazy per @Antoine’s suggestion also suffers from being not scalable. If you plan to publish your plug-in for other people to use, while you may think your plug-in is important enough to start early, your user may disagree.

By: Antoine Toulme

Antoine Toulme — Sun, 01 Mar 2009 15:46:58 +0000

I second what Robert said, and you should just make the bundle non-lazy, so it will start without being required by another bundle.

By: Radoslaw Urbas

Radoslaw Urbas — Sun, 01 Mar 2009 15:23:50 +0000

Robert – that’s very good suggestion, thanks! The job lifecycle should be mantained by start()/stop() methods of plug-in’s Activator. But I still want this bundle to activate automatically (it is supposed to be independent, no one other bundle is supposed to reference it) – is there any better option than org.eclipse.ui.startup extension-point for this?

By: Robert Konigsberg

Robert Konigsberg — Sun, 01 Mar 2009 15:09:48 +0000

I would strongly discourage using (and at work, be discouraged to use) early startup for this purpose for four reasons: one, because it delays the IDE startup, a solution that does not scale when implemented by a large number if plug-ins; two, because you can’t stop the job when the IDE shuts down; and three, you can’t reference your plug-in or any other plug-in until it too has started

Instead I would use the plug-in’s lifecycle methods start() and stop() to control when the job starts and stops. Make the job a private member of the plug-in and everything plays well together.

By: Frederic

Frederic — Sun, 01 Mar 2009 13:49:53 +0000

Could be an option for simple task scheduling. For more complex job schedules, use http://www.opensymphony.com/quartz/