Best way to deploy updated bundles/configurations with the OSGi Installer and the JCR Installer via FileVault packages

[Konrad Windszus <ko...@gmx.de>]

I am still wondering what is the best way to deploy updated bundles/configurations with the help of the JCR Installer and FileVault packages while preventing to much restart of services on the OSGi level.

The problem is that for an update there is the slight chance, that the deletion of the old bundle/config and the addition of the new bundle/config is not processed in the same cycle of the OSGi installer. In case this happens, then a lot more starting/stopping of services/bundles happens as instead of the upgrade an individual delete followed by an individual addition is detected.

What is the recommended way of minimizing that risk in my package?

The following options come to my mind:
1. Do not delete the old artifact (only possible for bundles, as the node name includes the version number by default). To achieve that the filter roots only point to the simple file aggregates covering the current bundle only (and not touching the old one)
2. Make sure that you have dedicated root entries for the the bundles/configs only (e.g. "/apps/myapp/install"). I am not sure though if this actually makes a difference in terms of how much this minimizes the timespan of old artifacts being deleted and new artifacts being added. In most of the cases the deletion as well as the addition should anyhow be done in the same JCR session (as an autocommit only happens every 1024 nodes).

Are there any other choices?
What is the recommended way here?

Thanks for your input,
Konrad

Re: Best way to deploy updated bundles/configurations with the OSGi Installer and the JCR Installer via FileVault packages

[Tobias Bocanegra <tr...@adobe.com>]

Hi Konrad,

I think it's better to include only the specific bundle in the filter, so that there are less conflicts when installing. It also allows for simpler uninstallation as just he node needs to be removed. However, in most production environment, code upgrades are costly and must allow for scheduled downtime. 

Btw: I think that the people on the sling list can probably give better answers :-)

Regards, Toby

> On 9 Apr 2018, at 23:45, Konrad Windszus <ko...@gmx.de> wrote:
> 
> I am still wondering what is the best way to deploy updated bundles/configurations with the help of the JCR Installer and FileVault packages while preventing to much restart of services on the OSGi level.
> 
> The problem is that for an update there is the slight chance, that the deletion of the old bundle/config and the addition of the new bundle/config is not processed in the same cycle of the OSGi installer. In case this happens, then a lot more starting/stopping of services/bundles happens as instead of the upgrade an individual delete followed by an individual addition is detected.
> 
> What is the recommended way of minimizing that risk in my package?
> 
> The following options come to my mind:
> 1. Do not delete the old artifact (only possible for bundles, as the node name includes the version number by default). To achieve that the filter roots only point to the simple file aggregates covering the current bundle only (and not touching the old one)
> 2. Make sure that you have dedicated root entries for the the bundles/configs only (e.g. "/apps/myapp/install"). I am not sure though if this actually makes a difference in terms of how much this minimizes the timespan of old artifacts being deleted and new artifacts being added. In most of the cases the deletion as well as the addition should anyhow be done in the same JCR session (as an autocommit only happens every 1024 nodes).
> 
> Are there any other choices?
> What is the recommended way here?
> 
> Thanks for your input,
> Konrad
>