Hi all, We upgraded from AEM 6.4 to AEM 6.5 last week and unfortunately we learned about DLCM.
Before AEM 6.5 we had absolutely no trouble to keep the AEM author online while deploying and had no JSP/HTL errors during deploys. As of AEM 6.5 that changed for the worse. Because of all the Sling models we use, every we time we deploy any of our applications, DLCM gets unregistered/registered, causing also the JSP/HTL compilation to fail. This results in the author UI responding with HTTP 404 messages until DLCM is registered and active again. In the log files, this looks like: 20.11.2020 14:31:18.385 *DEBUG* [OsgiInstallerImpl] org.apache.sling.commons.classloader.impl.Activator Dynamic Class Loader is reloaded because it has previously loaded classes from bundle '[blanked-out]' which is no longer active ... 20.11.2020 14:31:18.928 *INFO* [OsgiInstallerImpl] org.apache.sling.scripting.sightly Service [org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler,41500, [org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler]] ServiceEvent UNREGISTERING As of that point, navigating around in the UI results in browser errors like: Missing Compilation Support. Cannot serve request to /sites.html/content/[blanked-out] in /libs/granite/ui/components/shell/header/user/user.html Exception: javax.script.ScriptException: Missing compilation support. at org.apache.sling.scripting.sightly.impl.engine.SightlyScriptEngine.compile(SightlyScriptEngine.java:60) ... A while (10-60 seconds, depending on the application being deployed) later, the logs look like: 20.11.2020 14:31:32.219 *INFO* [OsgiInstallerImpl] org.apache.sling.scripting.sightly Service [org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler,44334, [org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler]] ServiceEvent REGISTERED 20.11.2020 14:31:32.232 *INFO* [OsgiInstallerImpl] org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler Activating org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler And after that, all is fine again. As this post is already a year old, I’m wondering if there was any progress in this area? I also noticed a (significant?) difference in the org.apache.sling.scripting.sightly.impl.engine.compiled.SlingHTLMasterCompiler class. There the DLCM is referenced with the greedy option, while in org.apache.sling.scripting.sightly.models.impl.SlingModelsUseProvider and org.apache.sling.scripting.jsp.JspScriptEngineFactory this is referenced with the reluctant option. Can anyone explain why this is the case? I can only hope this gets fixed/improved in Apache Sling soon and see it appear in an upcoming AEM 6.5 Service Pack. Kind regards and hope to hear something soon, Wim Symons P.S. I hope this gets attached to the correct thread. On 2019/10/25 09:07:42, Julian Sedding <mailto:j...@gmail.com> wrote: > @Konrad: I agree that on AEM the JCR package manager is the main> > issue. However, I believe the JSP implementation of the REST API has> > already been replaced with the PackageManagerServlet. The problem is> > that the PackageManagerServlet has a reference to the DCLM in order to> > allow InstallHook implementations to load classes from OSGi.> > > Regards> > Julian> > > On Fri, Oct 25, 2019 at 8:51 AM Konrad Windszus <mailto:ko...@gmx.de> wrote:> > >> > > One of the main issues with the DCLM restart is the availability of the AEM > > package manager itself. As the AEM package manager ReST endpoint depends as > > well on the DCLM (written in JSP) it is usually restarted after a bundle > > deployment triggered by package installation (and therefore for quite a > > time no longer available for a subsequent package installation). Although > > some of the pain has been taken with > > https://issues.apache.org/jira/browse/SLING-3747 > > <https://issues.apache.org/jira/browse/SLING-3747>, it is still an issue > > for subsequent package installations.> > > I guess much of the pain would already be resolved in case something like > > https://issues.apache.org/jira/browse/JCRVLT-151 > > <https://issues.apache.org/jira/browse/JCRVLT-151> would be implemented in > > a way which doesn't rely on scripts (but rather on precompiled servlets).> > > Konrad> > >> > >> > > > On 22. Oct 2019, at 10:21, Konrad Windszus <mailto:ko...@gmx.de> wrote:> > > >> > > > Hi Julian,> > > > thanks a lot for bringing up this topic. Indeed the restart cascade > > > causes some issues for me as well. Just invalidating the cache of the > > > DCLM without restarting it fully sounds reasonable to me, but I am not > > > that familiar with class loader insights. I vaguely remember that the > > > restart might be necessary due to static cache fields but I don't > > > remember the details...> > > > Maybe Carsten remembers...> > > > Konrad> > > >> > > >> On 22. Oct 2019, at 10:00, Julian Sedding <mailto:js...@gmail.com> > > >> wrote:> > > >>> > > >> Hi all> > > >>> > > >> I have observed repeatedly that reinstalling bundles of a custom Sling> > > >> (actually AEM) application causes a lot of activity in the OSGi> > > >> framework and thus can take quite a long time (10s of seconds to> > > >> minutes), which feels quite disruptive during development where> > > >> frequent deployments are common.> > > >>> > > >> As far as I can see the Dynamic Class Loader Manager (DCLM) does "the> > > >> right thing" and restarts itself when a bundle whose classes have been> > > >> loaded via the dynamic class loader is reinstalled. The restart of the> > > >> DCLM then causes all services referencing it to restart as well,> > > >> causing, amongst others, scripting engines to restart and generally> > > >> triggering a cascade of service restarts.> > > >>> > > >> This seems to be especially common with bundles providing model> > > >> classes that are used in rendering scripts (a prime use-case for> > > >> customizations), but is not limited to such cases. Note: it is> > > >> necessary to run a rendering script using the model before> > > >> reinstalling the bundle in order to cause the restarts> > > >>> > > >> I was wondering if it wouldn't be possible to change the DCLM in a way> > > >> that it doesn't need to restart, but that it just swaps out the class> > > >> loader(s) behind the facade.I don't have much experience with> > > >> implementing custom class loaders, but I have a hunch that this may be> > > >> difficult to get right due to class loader internal caching of loaded> > > >> classes.> > > >>> > > >> Is there anyone more knowledgable in this area who could provide an> > > >> assessment regarding the feasibility of such an approach?> > > >>> > > >> Regards> > > >> Julian> > > >> > >> > -- Disclaimer -- Vlaamse Radio- en Televisieomroeporganisatie Auguste Reyerslaan 52 1043 Brussel nv van publiek recht BTW BE 0244.142.664 RPR Brussel VRT Gebruikersvoorwaarden <http://www.vrt.be/gebruiksvoorwaarden>
