[
https://issues.apache.org/jira/browse/SLING-4851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620447#comment-14620447
]
Bertrand Delacretaz commented on SLING-4851:
--------------------------------------------
At revision 1690079 I have moved the experimental modules under [1] and
implemented a {{StartLevelController}} with a mechanism to wait for OSGi
installer resources that are slow to install (or any other slow operation) when
increasing the start levels.
The {{IncrementalStartupIT}} test passes with the following scenario:
* Use the {{StartLevelController}} to increase the start level
* When the a "start level changed" framework event is received for start level
N, register a bunch of new bundles as {{InstallableResources}} for the OSGi
installer, which works mostly asynchronously
* Each bundle includes an Activator which takes about 100msec to execute,
randomly
* The activator verifies that when it's done the start level is still N
Out of the box this doesn't work when switching from start level 5 to 15 for
example, the activators of bundles registered at level 6 might end their
execution at level 8 or 9 depending on timings. The goal is to simulate a
startup where many things are registered with the OSGi installer as start
levels go up, and take time to be fully installed.
To solve this I've tried a new approach, with this interface
{code}
public interface StartLevelChangeBarrier {
/** Optionally return a latch that must have
* a zero value before the start level change
* is considered complete. Called by the {@link StartLevelController}
* right after increasing the start level.
*
* @param startLevel the start level that was just switched to
* @return a latch or null if none is needed for this level.
* The initial value of the latch is meaningless,
* it's just the latch reaching zero that is important.
* If a client needs complex logic to find out when things
* are ready, it can return a latch with an initial value
* of 1 and just bring that down to zero when ready.
*/
CountDownLatch getStartLevelLatch(int startLevel);
}
{code}
This is implemented by my test code to return a CountDownLatch initialized with
the number of bundles that will be registered for the supplied startLevel
value. Those bundle's activators then decrement the counter when done, and as a
result the StartLevelController correctly waits for all of them to be started
before proceeding to the next start level.
This is just a proof of context of course, I guess the main questions now are
whether a) we like this {{StartLevelChangeBarrier}} mechanism, and whether b)
having to use a new {{StartLevelController}} to get a sequenced increase of
start levels is acceptable.
For b) we might be able to use a {{FindHook}} to hide the standard start level
services and replace them with our custom one, but going through the
{{StartLevelController}} might be ok as well as this is only needed during
startup AFAIK.
Besides being decoupled from our launchpad code the big advantage of this
mechanism is that it avoids the arbitrary 2 seconds delay that the current
{{DefaultStartupHandler}} uses to let the installer react to a change of start
levels. The installer should be able to find out what needs to be waited for on
a start level change and provide that information via a
{{StartLevelChangeBarrier}} service.
[1] https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/startup-stuff/
> Extract the launchpad startup logic in separate bundles
> -------------------------------------------------------
>
> Key: SLING-4851
> URL: https://issues.apache.org/jira/browse/SLING-4851
> Project: Sling
> Issue Type: Bug
> Components: Launchpad
> Reporter: Bertrand Delacretaz
> Assignee: Bertrand Delacretaz
>
> The launchpad currently embeds the incremental startup logic (in
> DefaultStartupHandler) as well as the StartupMode detection logic in a way
> that's tightly linked to the launchpad runnable jar.
> In other to make these functionalities available to other startup
> environments (Karaf, Crankstart etc.) we need to extract them into a separate
> bundle that can be installed at start level 1 to provide these functions with
> any OSGi launcher.
> We might create two bundles, one for incremental startup and one for startup
> mode detection. For now I have started to experiment with tests at
> https://svn.apache.org/repos/asf/sling/whiteboard/bdelacretaz/it-startup to
> have a baseline before moving things out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
