I've committed a patch which will now unregister the resource resolver factory if a resource provider factory is unregistered. This is actually very simple as we already have all the code in the right place (ResourceresolverFactoryActivator). I tested this a little bit and it seems too not cause problems
Carsten 2014-02-21 9:37 GMT+01:00 Carsten Ziegeler <cziege...@apache.org>: > 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 > -- Carsten Ziegeler cziege...@apache.org
