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
