Hi Wim I looked into this issue back then and concluded that it may not be feasible at all to (significantly) improve the restart-performance of the DCLM. The reason is that it is very hard or impossible to correctly replace class-loaders due to JVM internal caching (I forgot the details, it's been a while). If resolving this is at all possible, it would IMHO require a lot of time.
However, I had success improving performance of deployments on AEM 6.5 by following an (unrelated) suggestion by Jörg Hoh: https://cqdump.wordpress.com/2020/07/13/slow-deployments-on-aem-6-4-6-5/ The only other thing I know can help is keeping models in a separate bundle from your other code. If no other bundles improt code from your model-bundle, their restart is cheaper. Regards Julian On Fri, Nov 27, 2020 at 9:50 AM Wim Symons <wim.sym...@vrt.be> wrote: > > 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> >
