[
https://issues.apache.org/jira/browse/FELIX-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15584684#comment-15584684
]
Guillaume Nodet commented on FELIX-5383:
----------------------------------------
The Blueprint Extender is supposed to not start bundles before their
dependencies are satisfied, and in all cases, this is supposed to happen
asynchronously.
What you describe implies that the Gemini Blueprint Extender will synchronously
start the bundle, even if its dependencies are not satisfied and block the
whole framework startup in doing so. This would clearly be a big problem in
Gemini Blueprint if that's the case.
In all cases, a bundle that blocks while starting, or an extender that makes a
bundle start block forever is really behaving badly.
I really suggest you investigate the above issue, eventually consider switching
to a better blueprint implementation if needed.
> Support parallel bundle starting
> --------------------------------
>
> Key: FELIX-5383
> URL: https://issues.apache.org/jira/browse/FELIX-5383
> Project: Felix
> Issue Type: Improvement
> Components: File Install
> Affects Versions: fileinstall-3.5.4
> Reporter: Matt Magoffin
> Assignee: Guillaume Nodet
>
> I have an application that uses Felix File Install to start a set of bundles
> that use Blueprint configuration extensively, but with the poll time disabled
> ({{felix.fileinstall.poll = 0}}) because I only want the bundles started at
> application startup time. Sometimes one bundle might have a Blueprint service
> dependency provided by another bundle such that when started and that other
> bundle has not been started yet causes a service timeout. The ordering File
> Install uses to start bundles is indeterminate (a {{HashSet}} is passed to
> {{startBundles(Collection<Bundle> bundles)}}) so I thought a good solution
> would be to start bundles in parallel, so if one bundle gets stuck when
> starting, waiting for a Blueprint service to become available, other bundles
> can continue to be started under the assumption one of them will be providing
> that service "soon".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
