Possible timing issue with JcrInstaller + Config Writeback

[Julian Sedding <js...@gmail.com>]

Hi all (and Carsten in particular)

I observed the following situation on a Sling instance (CQ 5.6.1
actually) with jcr provider version 3.1.6 installed. After installing
a Jackrabbit FileVault package with multiple configurations in
multiple run-mode specific folders, an incorrect configuration was
active and written back to the repository.

The following two configurations are installed as sling:OsgiConfig
nodes (names shortened for readability), runmode "prod" is active:

/apps/foo/config/o.a.s.c.log.LogManager.factory.config-foobar (log-level: debug)
/apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar
(log-level: warn)

A few seconds after the installation of this package the second
configuration is replaced by

/apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar.config
(log-level: debug).

Now my hypothesis:
During installation of JR FileVault packages changes are saved every
~1024 nodes. I assume the first configuration node is saved before the
"prod"-specific one.

The first config node is scheduled for installation, installed and
ConfigAdmin fires a config added or changed event, triggering a
write-back. However, in the meantime JcrInstaller has discovered the
"prod"-specific config node and, because it has a higher weight,
selects its location for the write-back. The related InstallResource
task for the "prod"-specific config then leads to a no-op, because
after the writeback it is identical to the first config.

Does this scenario sound plausible at all?

Thanks for any insights.

Regards
Julian

Re: Possible timing issue with JcrInstaller + Config Writeback

[Carsten Ziegeler <cz...@apache.org>]

Am 21.10.15 um 11:52 schrieb Julian Sedding:
> Hi all (and Carsten in particular)
> 
> I observed the following situation on a Sling instance (CQ 5.6.1
> actually) with jcr provider version 3.1.6 installed. After installing
> a Jackrabbit FileVault package with multiple configurations in
> multiple run-mode specific folders, an incorrect configuration was
> active and written back to the repository.
> 
> The following two configurations are installed as sling:OsgiConfig
> nodes (names shortened for readability), runmode "prod" is active:
> 
> /apps/foo/config/o.a.s.c.log.LogManager.factory.config-foobar (log-level: debug)
> /apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar
> (log-level: warn)
> 
> A few seconds after the installation of this package the second
> configuration is replaced by
> 
> /apps/foo/config.prod/o.a.s.c..log.LogManager.factory.config-foobar.config
> (log-level: debug).
> 
> Now my hypothesis:
> During installation of JR FileVault packages changes are saved every
> ~1024 nodes. I assume the first configuration node is saved before the
> "prod"-specific one.
> 
> The first config node is scheduled for installation, installed and
> ConfigAdmin fires a config added or changed event, triggering a
> write-back. However, in the meantime JcrInstaller has discovered the
> "prod"-specific config node and, because it has a higher weight,
> selects its location for the write-back. The related InstallResource
> task for the "prod"-specific config then leads to a no-op, because
> after the writeback it is identical to the first config.
> 
> Does this scenario sound plausible at all?
> 
Yeah, this might be the case. You can easily test by disabling the
intermediate saves.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org