search

valtech / aem-easy-content-upgrade

AEM Easy Content Upgrade simplifies content migrations in AEM projects
Other
61 stars 27 forks source link

After 6.5.8 takes longer to install #154

Closed pcastelog closed 2 years ago

pcastelog commented 3 years ago

Hi,

I identified a possible issue during the installation of the package in 6.5.8. The new Service Pack contains the fix for CQ-4312194 / FELIX-6252, this for some reason is causing more OsGi events for the bundle modified in this case "org.apache.felix.scr", then when the package is executing the hook to look for a quiet osgi events seems to not happen and takes up to 6-7 minutes to install (sometimes hanging forever). The issue can be reproduced via command-line deployment or package manager. I tried on a vanilla instance with groovy 14 + Aecu 3.2.0 and groovy 16 + aecu 4.0.0 and the behaviour is exactly the same. Could you also try it? I want to confirm that I'm not the only one with this issue.

Thanks in advance

pcastelog commented 3 years ago
Captura de pantalla 2021-04-30 a las 9 12 50
gruberrolandvaltech commented 3 years ago

This looks more like a product bug. We use waitForOsgiEventsQuietInSec from https://sling.apache.org/documentation/bundles/installer-provider-installhook.html.

pcastelog commented 3 years ago

Yes, I know. I already contacted Adobe Support, it was just to confirm.

gruberrolandvaltech commented 3 years ago

I do not see this issue locally. Let me know if you find any reason for the issue with Adobe.

gruberrolandvaltech commented 3 years ago

Any update on this from Adobe?

pcastelog commented 3 years ago

Not really, the suggestion was to increase the waiting time between package installations. Also, the cause for the increase of OsGi was not clarified. Anyway, this issue can be closed

ofarganc commented 2 years ago

We are still facing this issue, and it's getting worse because we want to automate deployment in Azure Cloud. Waiting for the clear console causes the deployment to get stale and never finish.

gruberrolandvaltech commented 2 years ago

@ofarganc do you see the same issue with AC Tool? It uses the same waiting mechanism.

ofarganc commented 2 years ago

Hi Roland! Thanks for the quick response. We didn't experience that problem with ACtool so far. As Pablo mentioned, AEM 6.5.12 is generating too many events. I will talk to Georg about this, but for the moment we'll have to remove AECU from our installation. Pablo had to do a manual install for it to work.

pcastelog commented 2 years ago

In this case, I was testing it with ACtools, and takes a bit more time 1:30 min to install but ends in a correct timeframe. For the AECU case you can reproduce it easily with the following step:

gruberrolandvaltech commented 2 years ago

I guess it is caused by this: java.lang.IllegalStateException: RRD already closed, cannot store this sample at org.rrd4j.core.RrdDb.store(RrdDb.java:512) at org.rrd4j.core.Sample.update(Sample.java:194) at org.apache.sling.commons.metrics.rrd4j.impl.RRD4JReporter.report(RRD4JReporter.java:260) at com.codahale.metrics.ScheduledReporter.report(ScheduledReporter.java:235) [com.adobe.granite.dropwizard.metrics:3.2.4] at com.codahale.metrics.ScheduledReporter$1.run(ScheduledReporter.java:174) [com.adobe.granite.dropwizard.metrics:3.2.4] at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)

gruberrolandvaltech commented 2 years ago

Fixed with https://github.com/valtech/aem-easy-content-upgrade/commit/18a28567e91ca99c67d00dde6cc87666d07a53f8 At the end, this is just a workaround. The RRD exception comes every 5s and switching our check from 7s to 4s avoids the issue.