Extenders: Pattern or Anti-Pattern?
The extender pattern has become popular in recent years and has even been utilised in OSGi standards such as the Blueprint service and the Web Applications specification. In Virgo, we've been working with extenders from the start, but in spite of their advantages, they have some significant downsides. Since the OSGi Alliance is considering using extenders in other specifications, I agreed to document some of the issues.
The first difficulty is knowing when an extender has finished processing a bundle. For example, a bundle containing a blueprint XML file will transition to ACTIVE state as soon as any bundle activator has been driven. But that's not the whole story. Administrators are interested in when the bundle is ready for use and so the management code in Virgo tracks the progress of the extender and presents an amalgamated state for the install artefact representing the bundle. The install artefact stays in STARTING state until the application context has been published, at which point it transitions to ACTIVE. Without such additional infrastructure, administrator cannot tell when a bundle processed by an extender really is ready for business.
That's the successful case, but there are complications in error cases too. The first complication is that since an extender runs in a separate thread to that which installed the bundle, if the extender throws an exception, this is not propagated to the code which installed the bundle. So the installer needs somehow to check for errors. Therefore Virgo has infrastructure to detect such errors and propagate them back to the thread which initiated deployment of the bundle: the deployment operation fails with a stack trace indicating what went wrong.
The other error complication is where there is a (possibly indefinite) delay in an extender processing a bundle. For this kind of error Virgo tracks the progress of extender processing and issues warnings to the event log (intended for the administrator's eyes) saying which pieces of processing have been delayed and in some common situations, for example when a blueprint is waiting for a dependency, what is causing the delay.
Extenders suffer from needing to be able to see bundle lifecycle events and so for systems that partition the framework, it is necessary to install each extender into multiple partitions. On the flip side it is crucial to prevent multiple instances of an extender from ever seeing the same bundle event otherwise they will both attempt to extend the bundle.
Another issue with extenders is the need to keep them running and healthy as there is little indication that an extender is down or sickly other than bundles not being processed by the extender. Virgo takes care to ensure its extenders are correctly started and its infrastructure for detecting delays helps to diagnose extender crashes or sickness (both of which are extremely rare situations).
There is also an issue in passing parameters to an extender to affect its behaviour. This is typically done by embedding extender configuration in the bundles being processed or by attaching a fragment containing configuration to the extender bundle. But since the extender is not driven by an API, the normal approach of passing parameters on a call is not available. Essentially, an extender model implies that the programming model for deployment is restricted to BundleContext.installBundle.
With considerable investment in additional infrastructure, Virgo has managed to support the Blueprint and Spring DM extenders reasonably well. But in the case of the Web Applications extender, Virgo couldn't make this sufficiently robust and so it drives the underlying web componentry directly from the Virgo deployment pipeline to avoid the above issues.
I understand at least one other server runtime project has encountered similar issues with extenders, so Virgo is not alone. There is a trade-off between loosely coupling the installer from the resource-specific processing, the main strength of the extender pattern (but far from unique to that pattern), and providing a robust programming model and usable management view -- crucial features of a server runtime -- which is far more straightforward without extenders.
4 comments:
It is also not possible to detect the presence of an Extender without knowing specifics of its implementation. I may have a bundle that wants to take different action if an Extender is present or not. For example the Web Extender, my bundle may want to fall back and try the HTTPService if it's not going to get picked up by the Web Extender.
Chris
> Without such additional infrastructure, administrator cannot tell when a bundle processed by an extender really is ready for business.
Without sufficient knowledge, no one can tell when _any_ bundle is ready for business. The completion of the bundle activator does not imply ready for business since the bundle may require services not currently available or have some long running initialization going in a separate thread.
The extender pattern is an event driven pattern which is asynchronous by nature. Synchronous API models also have their limitations.
Hi BJ. Fair point. It's interesting that, for instance, the Blueprint service plus appropriate monitoring can usually cope with those cases. Missing dependencies delay the blueprint from being built; long running initialisation can be performed on the extender thread. The crucial thing is that a standard service is published when the blueprint initialisation is finished. Perhaps we need to generalise that approach so that non-extended bundles can also signal the completion of their (asynchronous) initialisation in a standard way.
> The crucial thing is that a standard service is published when the blueprint initialisation is finished.
As already indicated earlier: "initialization finished" doesn't say anything about whether the bundle is ready for business (which is about the same statement as made by 121.3.7 from the blueprint specification v1.0).
Therefore, for administrator purposes I think it would be nice to see some kind of backtrack information about service dependencies. For example:
- Bundle Z is waiting for service A.
- An instance of service A would be published by bundle Y if it could satisfy a reference to service type B.
- Etc.
In the current specification of blueprint, this is not possible because there is no option to de-register services when dependency services disappear.
P.S. I know that getting the information right is not a trivial thing to do.
Post a Comment