Hi Jörg I would argue that a new ResourceResolver for each "onEvent" call would be advisable. Not only to avoid the problem you observe, but also to avoid the risk of the session being used concurrently from multiple threads. Not sure if JCR event hanlders may be called concurrently though.
The alternative, which doesn't guard against concurrent use, would be to call refresh on the long-lived ResourceResolver, which you use to register the JCR event listener, as the first thing in the "onEvent" call. This will also refresh the internal "resourceTypeResourceResolver" if it exists (it is created when isResourceType() is called for the first time on a ResourceResolver, and it is bound to that ResourceResolver's life-cycle). Regards Julian On Mon, Aug 27, 2018 at 10:38 AM Jörg Hoh <[email protected]> wrote: > > Hi all, > > I just came across an exception which makes me wonder how to adress it; > it's a JCR observation listener, which has been opened on the JCR session > of a Sling ResourceResolver. And inside of the event handler the > isResourceType() method of the Resource Resolver is called. > > 27.08.2018 11:16:42.092 *WARN* [sling-oak-observation-1] > org.apache.jackrabbit.oak.jcr.session.RefreshStrategy This session has been > idle for 1 minutes and might be out of date. Consider using a fresh session > or explicitly refresh the session. > java.lang.Exception: The session was created here: > at > org.apache.jackrabbit.oak.jcr.session.RefreshStrategy$LogOnce.<init>(RefreshStrategy.java:170) > at > org.apache.jackrabbit.oak.jcr.repository.RepositoryImpl.login(RepositoryImpl.java:285) > ... > at > org.apache.sling.resourceresolver.impl.ResourceResolverImpl.isResourceType(ResourceResolverImpl.java:1236) > at > org.apache.sling.api.resource.AbstractResource.isResourceType(AbstractResource.java:121) > at com.mycorp.some.Observation.Listener.onEvent(Listener.java:273) > at > org.apache.jackrabbit.commons.observation.ListenerTracker$1.onEvent(ListenerTracker.java:190) > at > org.apache.jackrabbit.oak.jcr.observation.ChangeProcessor.contentChanged(ChangeProcessor.java:508) > > For me it seems that with the call of the "isResourceType" method a second > ResourceResolver (the "type resource resolver") is opened which is backed > by a JCR session as well. But because this session lives in the context and > livecycle of the single ResourceResolver (which is primarily used for the > JCR observation), it's a long running session and would need a timely > refresh. > > What's the best way to solve this and avoid the WARN message? Use a > dedicated session when doing the type checks, so the resource resolvers are > not tied to a single livecycle? Also just adding some refresh() statements > to the type resolver seems not good, because then the type resolver might > see a different state of the repo than the other ("main") session. > > Jörg > > > -- > Cheers, > Jörg Hoh, > > http://cqdump.wordpress.com > Twitter: @joerghoh
