[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[virgo-dev] Virgo fails to start if BundleException is thrown on startup (Bugzilla 322132)
- From: Steve Powell <spowell@xxxxxxxxxx>
- Date: Tue, 10 Aug 2010 10:00:46 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Delivered-to: firstname.lastname@example.org
- Thread-index: Acs4rZOLDrLmO8bLRu+3zMsQ5RmTzg==
- Thread-topic: Virgo fails to start if BundleException is thrown on startup (Bugzilla 322132)
This is an interesting one, so I propose to open it up for discussion.
Hristo Iliev raised a bug , a perfectly valid bug, which concerns a failure during initialisation of the kernel region. In particular if one of the bundles which are launched (see the launch.bundles property in org.eclipse.virgo.kernel.launch.properties) fails during start (with a BundleException for example), then the system can enter a strange state.
Clearly this is a serious problem:
The launch.bundles list is first installed, and then each one marked 'start' is started in turn, all of these initial starts occur serially on one thread.
If an exception is thrown by an activator (or by the framework) then the exception is reported but the Launcher (part of osgi-extensions) simply aborts.
The Launcher is the main program that is started by the dmk script, so when this main thread terminates everything else should as well, except that the other framework threads now run independently. This is normal.
The result is that whatever was started properly remains started, and no further bundles are started after the Bundle (or IO) Exception occurs.
The first proposal is as follows:
Launch calls builder.start() (on a FrameworkBuilder instance -- which, by the way, is not, strictly speaking, a reification of a Builder pattern) and proceeds as now -- serially starting the bundles in the list.
If any of the bundle.start() methods should throw an exception, the bundles already started are stopped, serially, in reverse order, before exiting from builder.start() with the exception.
The second proposal is as follows:
- Launch calls (builder.start() which calls) install and start as today....
- If a bundle.start() method should throw an exception, then the bundle which failed is uninstalled and the start() process continues. Exceptions are recorded on the log.
The first proposal has the following merits:
- Failures during startup do not leave the kernel in an intermediate state.
- Kernel configuration errors do not go 'unnoticed'.
- Kernel startup remains predictable and controllable.
The second proposal has the following merits:
- A failure of an unimportant bundle doesn't cause the whole kernel to fail.
- Failures during startup might be amenable to framework analysis if sufficient parts of the kernel remain active.
(I hope I've represented this correctly, Hristo. Post here if not.)
I prefer the first proposal.
Here is my critique of the second proposal:
- Firstly, changes to the kernel startup configuration are rare, and this is not likely to be happening in production.
- Bundles that simply >must< be launched with the kernel framework are unlikely to be minor. If a bundle is sufficiently trivial it ought to be installed and started independently -- maybe in an initial plan. If not, we cannot (and should not) tolerate its failure.
- It is hard for the Launcher/FrameworkBuilder to know which bundles are essential and which not, so no intelligent decision can be made at run-time.
- Partial failures during startup will lead to unpredictable kernel runtime configurations, which in turn will lead to inconsistent and hard-to-detect failures during normal application running. Let's not go there.
- It is better to fail completely than to continue and give the (false) appearance of health and good behaviour.
Over to you all...
 Bug 322132<https://bugs.eclipse.org/bugs/show_bug.cgi?id=322132> BundleException causes Virgo startup to fail.
[W:+44-2380-111-528; M: +44-7815-838-558; H:+44-1962-775-598]
Cannelloni n. A narrow boat for one. [SPD]
Verisimilitude adj. Extremely evenly masticated. [SPD]
Decrepit v. To muck-out Royal stables. [SPD]