felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5383) Support parallel bundle starting
Date Tue, 18 Oct 2016 18:59:58 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586340#comment-15586340

Guillaume Nodet commented on FELIX-5383:

Fwiw, synchronous start is not a problem if there will be no wait.  For example aries-bueprint
can be configured to start bundles synchronously, but will only do so as long as it will not
wait for a dependency.  If it enters the grace period, it will resume asynchronously when
the dependency is later satisfied.

> 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

View raw message