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
