You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Jörg Hoh <jh...@googlemail.com.INVALID> on 2018/08/27 10:38:26 UTC
JCR Observation, Type ResourceResolver & idle JCR sessions
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
Re: JCR Observation, Type ResourceResolver & idle JCR sessions
Posted by Jörg Hoh <jh...@googlemail.com.INVALID>.
Hi Julian,
Am Mo., 27. Aug. 2018 um 13:51 Uhr schrieb Julian Sedding <
jsedding@gmail.com>:
> 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.
>
IIRC multiple handlers can run in parallel, but as observation must be
handled in a strict serialized way, the sme handler is not running
concurrently. Also creating new sessions / resource resolvers for each
event can be quite some overhead, especially if a lot of events needs to be
considered.
>
> 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).
>
>
I guess that's the best way to handle this. I will recommend it.
Thanks!
Jörg
--
Cheers,
Jörg Hoh,
http://cqdump.wordpress.com
Twitter: @joerghoh
Re: JCR Observation, Type ResourceResolver & idle JCR sessions
Posted by Julian Sedding <js...@gmail.com>.
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
<jh...@googlemail.com.invalid> 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