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
