[jira] [Comment Edited] (FELIX-5383) Support parallel bundle starting

["Matt Magoffin (JIRA)" <ji...@apache.org>]

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

Matt Magoffin edited comment on FELIX-5383 at 10/17/16 10:09 PM:
-----------------------------------------------------------------

Here's a fork of the 3.5.4 release of File Install where I implemented this concept:

https://github.com/msqr/felix/blob/fileinstall-start-async

The [changes are in DirectoryWatcher.java|https://github.com/apache/felix/compare/org.apache.felix.fileinstall-3.5.4...msqr:fileinstall-start-async], mostly [centered around|https://github.com/msqr/felix/blob/5769cdc57060026b9f3e62ddc9f1cb6144bb4a19/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L1245] the {{startBundles(Collection<Bundle> bundles)}} method.

The changes introduce two configurable properties:

1.  {{felix.fileinstall.start.tasks}} for the maximum number or parallel start tasks to execute, or if >= 99 than unlimited.
2. {{felix.fileinstall.start.tasksRetryDelay}} for a number of seconds to delay before re-trying to start bundles that failed to do so.

The {{tasksRetryDelay}} property was needed because if, like in my case, the {{poll}} time is set to {{0}} then there needs to be a way to retry starting failed bundles.

This was my first time looking at the File Install code, so I'm not confident the changes are completely appropriate, but hopefully the idea of parallel starting is useful to others more generally.


was (Author: msqr):
Here's a fork of the 3.5.4 release of File Install where I implemented this concept:

https://github.com/msqr/felix/blob/fileinstall-start-async

The [changes are in DirectoryWatcher.java|https://github.com/msqr/felix/commit/5769cdc57060026b9f3e62ddc9f1cb6144bb4a19], mostly [centered around|https://github.com/msqr/felix/blob/5769cdc57060026b9f3e62ddc9f1cb6144bb4a19/src/main/java/org/apache/felix/fileinstall/internal/DirectoryWatcher.java#L1245] the {{startBundles(Collection<Bundle> bundles)}} method.

The changes introduce two configurable properties:

1.  {{felix.fileinstall.start.tasks}} for the maximum number or parallel start tasks to execute, or if >= 99 than unlimited.
2. {{felix.fileinstall.start.tasksRetryDelay}} for a number of seconds to delay before re-trying to start bundles that failed to do so.

The {{tasksRetryDelay}} property was needed because if, like in my case, the {{poll}} time is set to {{0}} then there needs to be a way to retry starting failed bundles.

This was my first time looking at the File Install code, so I'm not confident the changes are completely appropriate, but hopefully the idea of parallel starting is useful to others more generally.

> 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)