sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Georg Henzler <ghenz...@apache.org>
Subject Re: Dynamic Class Loader Manager causes lots of service restarts
Date Fri, 25 Oct 2019 10:07:02 GMT
Big +1 to improve the situation

One thought to make it simpler (without knowing this piece of code very
well): As far as I understood there is exactly one instance of the 
dynamic
classloader at one time, and if classes that it delivered change, all
consumers are restarted. Could we not just work with multiple instances
that are used for different script paths (like there is one for every
level under /apps). Script engines could also keep their own set of
dynamic classloaders.

But maybe that's in the end the same complexity than using artificial
bundles... just an idea to explore options.

-Georg

On 2019-10-25 11:09, Julian Sedding wrote:
> Thanks Carsten for the hint about how to create artificial bundles on
> the fly. As you say refactoring towards that goal would be a
> significant undertaking.
> 
> Regards
> Julian
> 
> On Fri, Oct 25, 2019 at 7:34 AM Carsten Ziegeler <cziegeler@apache.org> 
> wrote:
>> 
>> 
>> Am 24.10.2019 um 11:29 schrieb Julian Sedding:
>> > Thank you for your insights, Carsten! That saves me hitting that wall ;)
>> >
>> > I'm curious how your idea with artificial bundles would work. Would
>> > the scripts in the resource tree be exposed via one or more artificial
>> > bundle, each, importing the packages required by the scripts? And then
>> > the scripting engines could run the scripts using the bundle class
>> > loader of these artificial bundles. Is that right?
>> >
>> Yes, something along those lines. It makes sense to have more than one
>> artifical bundle otherwise again you have one bundle with a very large
>> list of imports.
>> 
>> > If that is correct, I guess that would benefit from the upcoming OSGi
>> > Connect specification (if I recall the name correctly).
>> >
>> I assume you mean to install the artificial bundle? This can be done
>> without connect as you basically just have to create a jar file with a
>> manifest and then pass this as an input stream into the framework to
>> install it.
>> 
>> Regards
>> Carsten
>> 
>> > Regards
>> > Julian
>> >
>> > On Tue, Oct 22, 2019 at 12:44 PM Carsten Ziegeler <cziegeler@apache.org>
wrote:
>> >>
>> >> As Julian suspected class loaders are caching. Initially we tried just
>> >> swapping things in the background but that didn't work due to the class
>> >> loader caching and that's out of control.
>> >>
>> >> A better solution would be to avoid the DCLM completely and rather
>> >> leverage OSGi more by for example creating artificial bundles with
>> >> imports which are then used by scripting. Similarly all scripts are
>> >> currently loaded by a single class loader. If a class changes where just
>> >> one of the scripts is based on, everything is still reloaded. That's not
>> >> really modular :)
>> >>
>> >> Or in other words the problem could potentially be solved but that's a
>> >> rather larger work. Unless there is something we haven't thought of yet.
>> >>
>> >> Regards
>> >> Carsten
>> >>
>> >> Am 22.10.2019 um 10:21 schrieb Konrad Windszus:
>> >>> 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 <jsedding@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
>> >>>
>> >>
>> >> --
>> >> --
>> >> Carsten Ziegeler
>> >> Adobe Research Switzerland
>> >> cziegeler@apache.org
>> 
>> --
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org

Mime
View raw message