I just gave this a try run with a large application...and it seems that this is causing too much service registration changes as there are many components having a reference to the resource resolver...or in other words the app never finishes its startup
I guess the main problem is that now, the resource resolver is re-registered not just when a provider factory disappears but also wenn it appears. I'll give it a try with modifying the service registration when a resource resolver factory is unregistered. Carsten 2014-02-20 14:39 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>: > Yes, that sounds like the easiest option - it would mean that the resource > resolver factory is re-registered with every change to a resource provider > factory - which doesn't sound too bad to me > > Carsten > > > 2014-02-20 13:25 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>: > > Hi >> >> I see. >> >> Can this be easily "solved" by just making the ResourceProviderFactory >> reference in the ResourceResolverFactoryActivator a static reference with >> eager policyOption? >> >> Regards >> Felix >> >> Am 20.02.2014 um 13:21 schrieb Carsten Ziegeler <cziege...@apache.org>: >> >> > Only ResourceProviderFactories are affected - simple resourceProviders >> like >> > the servlet ones can't keep state. Those appear/disappear silently. I >> agree >> > that service registration modifications are rather expensive, on the >> other >> > hand there are only a few provider factories and those are usually not >> > updated frequently (of course, we never know what our users are doing). >> > >> > Your idea for keeping references to the entries makes sense, however >> today, >> > the resource resolver context is holding the reference to the factory - >> and >> > this needs to be nulled out in some way. We could maybe get away with an >> > intermediate ResourceProviderEntry. >> > >> > I'm still not sure if this is the right thing, as RPs from factories can >> > keep state, like transient changes and these would simply disappear- >> > >> > Carsten >> > >> > >> > 2014-02-20 13:09 GMT+01:00 Felix Meschberger <fmesc...@adobe.com>: >> > >> >> Hi >> >> >> >> Am 20.02.2014 um 10:19 schrieb Carsten Ziegeler <cziege...@apache.org >> >: >> >> >> >>> Hi, >> >>> >> >>> as noted in SLING-3400 we have a problem when a resource provider >> factory >> >>> is unregistered and a resource resolver is currently using a provider >> >> from >> >>> this factory. In that case, that reference is never cleared. >> >>> This problem occurs due to long running resource resolvers. >> >>> >> >>> I looked at solving this issue and my first idea was to simply remove >> the >> >>> reference to the provider if the factory is unregistered. >> Unfortunately, >> >>> this comes with the drawback that we have to keep a reference to all >> open >> >>> resource resolver (contexts) in order to notify them, once a factory >> is >> >>> removed. >> >>> Although this is feasible, while implementing it I came to the >> conclusion >> >>> that this is actually the wrong approach: a resource resolver is >> using / >> >>> has used a provider and this one silently disappears. This might cause >> >> some >> >>> trouble / unexpected behaviour. >> >>> >> >>> So I rather think, once this happens all resource resolvers need to be >> >>> closed and recreated - the easiest way to do this is to unregister and >> >>> reregister the resource resolver factory. However, I think simply >> >> modifying >> >>> the service registration of the resolver factory would be the better >> >> option >> >>> and should do the trick. >> >> >> >> This will be expensive since serlvets are registered as >> ResourceProviders >> >> this will cause all ResourceResolverFactory consumers to be "cycled" >> >> whenever a servlet is registered and unregistered. I think that is >> >> inappropriate overhead. >> >> >> >> Rather, I think it is perfectly fine to me, that we remove >> >> ResourceProvider instances used by ResourceResolver objects: At the >> end of >> >> the day, this is like removing JCR node subtree: A ResourceResolver >> cannot >> >> expect for this to exist for ever. >> >> >> >> Basically we have two cases: >> >> >> >> (1) ResourceProvider from ResourceProviderFactory >> >> (2) ResourceProvider service >> >> >> >> IIRC the second case of ResourceProvider services is easy because >> >> essentially a ResourceResovler instances share the same >> >> ResourceProviderEntry which in turn calls the ResourceProvider. >> >> Unregistering the ResourceProvider would just remove the >> ResourceProvider >> >> from the ResourceProviderEntry. >> >> >> >> For ResourceResourceProviderFactory it is a bit more complicated: >> Maybe we >> >> must keep a collection of ResourceProviderEntry instances which refer >> to >> >> the ResourceProvider instances provided by the ResourceProviderFactory. >> >> When the factory is unregistered the respective ResourceProvider >> instances >> >> are removed from the entries. >> >> >> >> Does that make sense ? >> >> >> >> Regards >> >> Felix >> >> >> >> >> >>> >> >>> WDYT? >> >>> >> >>> Regards >> >>> Carsten >> >>> -- >> >>> Carsten Ziegeler >> >>> cziege...@apache.org >> >> >> >> >> > >> > >> > -- >> > Carsten Ziegeler >> > cziege...@apache.org >> >> > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Carsten Ziegeler cziege...@apache.org
