OSGiInstallerHook is causing the deploy to be reaaally slow

[royteeuwen]

We are noticing that our deployments are failing because timeouts are being met, this being caused by the OSGiInstallerHook that is being used:

16.01.2025 06:07:40.000 *INFO* [CommitStats] CommitStats 12 commits by user translation-job-service from location other:java.base/java.lang.Thread.run(Thread.java:834) [CommitStats overhead was 3ms = 250.0us / commit]
16.01.2025 06:26:33.664 *INFO* [OsgiInstallerImpl] org.apache.sling.installer.provider.installhook.OsgiInstallerHook Waited 1480142ms in total for OSGi events to become quiet (for at least 5sec)
16.01.2025 06:26:33.665 *INFO* [OsgiInstallerImpl] org.apache.jackrabbit.vault Service [14619, [org.apache.sling.installer.api.event.InstallationListener]] ServiceEvent UNREGISTERING
16.01.2025 06:26:33.694 *INFO* [OsgiInstallerImpl] org.apache.jackrabbit.vault.packaging.impl.ActivityLog Netcentric:accesscontroltool-package:3.4.0: INSTALL
16.01.2025 06:27:42.754 *INFO* [OsgiInstallerImpl] org.apache.sling.installer.provider.installhook.OsgiInstallerHook Waited 7463ms in total for OSGi events to become quiet (for at least 4sec)
16.01.2025 06:27:42.755 *INFO* [OsgiInstallerImpl] org.apache.jackrabbit.vault Service [14659, [org.apache.sling.installer.api.event.InstallationListener]] ServiceEvent UNREGISTERING
16.01.2025 06:27:42.888 *INFO* [OsgiInstallerImpl] org.apache.jackrabbit.vault.packaging.impl.ActivityLog Valtech:aecu.complete:6.5.2: INSTALL

I'm suspecting that because there are two frameworks (accesscontroltool and aecu) using the same methodology, this might be causing deadlocks? Did you notice this before? any fix available for this?

[nhirrle]

Hello @royteeuwen

I haven't noticed this issue yet. I have aecu and AC Tool running but on AEM Cloud. This is then on AEM 6.5? Which versions exactly so we can reproduce?

Best, Nicolas

[royteeuwen]

@nhirrle this is indeed on 6.5.21, both packages are part of one big frameworks package containing all frameworks (jars / content packages we install). We migrated away from using the crx-quickstart/install folder for jars + separate content packages to this setup to be more in line with how AEMaaCS would work, and this is the result when trying to install on higher envs.

[nhirrle]

@royteeuwen I didn't went into details but it looks like the pitfalls described on the sling doc may be the root cause https://sling.apache.org/documentation/bundles/installer-provider-installhook.html#pitfalls-1
If you can create a reproducable case we can investigate further. Meanwhile you may want to have a separate aecu package with the installhook definition

[royteeuwen]

@nhirrle hmm, might be the case indeed, but that would make it impossible to ever add the aecu package as a subpackage to an all package that contains other frameworks like for example acs-commons as well? If I read it correctly, it's an issue from the moment that there is a restart of a lot of things, which is unavoidable in AEM6.5 sadly enough. Sounds like a major pitfall :(

I also have a complete log of a second run for the OSGi installer hook on trace:

osgi-installer.log