You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Roy Teeuwen <ro...@teeuwen.be> on 2019/03/27 18:58:35 UTC
Multiple threads on same resource resolver
Hey sling users,
This is a repost from the userlist of oak because I didn't get a reply there, so I hope I might get one here:
We have a system that migrates our sites based on migration rules, the psuedocode is as the following:
resourceResolver = getServiceResourceResolver("migration-user");
for(Site site in sites) {
migrateSite(resourceResolver)
}
Everything works fine, but we would like it more performant, so the change I did was the following:
resourceResolver = getServiceResourceResolver("migration-user");
for(Site site in sites) {
threadPool.submit(new Runnable() { run() {
migrateSite(resourceResolver)
});
}
This gave the following exception:
21.03.2019 11:32:47.244 *WARN* [sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4] org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to perform hasProperty while thread sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2 was concurrently writing to this session. Blocked until the other thread finished using this session. Please review your code to avoid concurrent use of a session.
So I decided to change the code to the following:
for(Site site in sites) {
threadPool.submit(new Runnable() { run() {
resourceResolver = getServiceResourceResolver("migration-user");
migrateSite(resourceResolver)
});
}
But it seems that the warn that is being thrown is still being thrown, does this mean that getting a new service resourceresolver based on the same user name still get into lockings / synchronizing issues? Is there any way to solve this?
Thanks,
Roy
Re: Multiple threads on same resource resolver
Posted by Julian Sedding <js...@gmail.com>.
Hi Roy
Do your Site objects reference a resource resolver instance, e.g. via
a resource? If they do then it's likely the warning comes from this RR
being used concurrently.
Other than that (bar closing the RRs in the thread), I can't see
anything obviously wrong with your last code snippet.
Regards
Julian
On Thu, Mar 28, 2019 at 10:01 AM Roy Teeuwen <ro...@teeuwen.be> wrote:
>
> Hey guys,
>
> Thanks for the replies.
>
> In the getServiceResourceResolver I do actually call resourceResolverFactory.getServiceResourceResolver, making it a new resource resolver instance for every thread. so in my knowledge this does create a new session, but it's on the same user name?
>
> Greets,
> Roy
>
> > On 28 Mar 2019, at 08:52, Michael Dürig <md...@apache.org> wrote:
> >
> >
> > Hi,
> >
> > Sorry for missing the original post on the Oak list.
> >
> > Like Carsten said, sessions do not support multiple threads. See also https://docs.adobe.com/docs/en/spec/jcr/2.0/4_Connecting.html
> >
> > The warning you receive is from a protection mechanism in Oak that prevents the worst. I.e. data corruption. However, there are no guarantees beyond that. E.g. performance or even progress (no deadlocks).
> >
> > Michael
> >
> >
> > On 28.03.19 07:32, Carsten Ziegeler wrote:
> >> Hi,
> >> a resource resolver is single threaded and must not be used concurrently by multiple threads. Main driver (but not the only one) is the JCR session which requires this.
> >> However, there is nothing in the Sling code base blocking you from doing so anyways. So we don't have any additional checks like Oak/Jackrabbit has. Therefore the log message you see, is initiated by Oak. I don't want to sent you from one list to another, but to my knowledge your latest code looks ok to me and I'm not aware that you can only have one thread for a service user. But maybe your getServiceResourceResolver method is always returning the same instance and not creating one per call? If not, I fear this is an issue for Oak.
> >> Regards
> >> Carsten
> >> Roy Teeuwen wrote
> >>> Hey sling users,
> >>>
> >>> This is a repost from the userlist of oak because I didn't get a reply there, so I hope I might get one here:
> >>>
> >>>
> >>> We have a system that migrates our sites based on migration rules, the psuedocode is as the following:
> >>>
> >>> resourceResolver = getServiceResourceResolver("migration-user");
> >>> for(Site site in sites) {
> >>> migrateSite(resourceResolver)
> >>> }
> >>>
> >>> Everything works fine, but we would like it more performant, so the change I did was the following:
> >>>
> >>> resourceResolver = getServiceResourceResolver("migration-user");
> >>> for(Site site in sites) {
> >>> threadPool.submit(new Runnable() { run() {
> >>> migrateSite(resourceResolver)
> >>> });
> >>> }
> >>>
> >>> This gave the following exception:
> >>>
> >>> 21.03.2019 11:32:47.244 *WARN* [sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4] org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to perform hasProperty while thread sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2 was concurrently writing to this session. Blocked until the other thread finished using this session. Please review your code to avoid concurrent use of a session.
> >>>
> >>> So I decided to change the code to the following:
> >>>
> >>> for(Site site in sites) {
> >>> threadPool.submit(new Runnable() { run() {
> >>> resourceResolver = getServiceResourceResolver("migration-user");
> >>> migrateSite(resourceResolver)
> >>> });
> >>> }
> >>>
> >>> But it seems that the warn that is being thrown is still being thrown, does this mean that getting a new service resourceresolver based on the same user name still get into lockings / synchronizing issues? Is there any way to solve this?
> >>>
> >>> Thanks,
> >>> Roy
> >>>
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziegeler@apache.org
>
Re: Multiple threads on same resource resolver
Posted by Roy Teeuwen <ro...@teeuwen.be>.
Hey guys,
Thanks for the replies.
In the getServiceResourceResolver I do actually call resourceResolverFactory.getServiceResourceResolver, making it a new resource resolver instance for every thread. so in my knowledge this does create a new session, but it's on the same user name?
Greets,
Roy
> On 28 Mar 2019, at 08:52, Michael Dürig <md...@apache.org> wrote:
>
>
> Hi,
>
> Sorry for missing the original post on the Oak list.
>
> Like Carsten said, sessions do not support multiple threads. See also https://docs.adobe.com/docs/en/spec/jcr/2.0/4_Connecting.html
>
> The warning you receive is from a protection mechanism in Oak that prevents the worst. I.e. data corruption. However, there are no guarantees beyond that. E.g. performance or even progress (no deadlocks).
>
> Michael
>
>
> On 28.03.19 07:32, Carsten Ziegeler wrote:
>> Hi,
>> a resource resolver is single threaded and must not be used concurrently by multiple threads. Main driver (but not the only one) is the JCR session which requires this.
>> However, there is nothing in the Sling code base blocking you from doing so anyways. So we don't have any additional checks like Oak/Jackrabbit has. Therefore the log message you see, is initiated by Oak. I don't want to sent you from one list to another, but to my knowledge your latest code looks ok to me and I'm not aware that you can only have one thread for a service user. But maybe your getServiceResourceResolver method is always returning the same instance and not creating one per call? If not, I fear this is an issue for Oak.
>> Regards
>> Carsten
>> Roy Teeuwen wrote
>>> Hey sling users,
>>>
>>> This is a repost from the userlist of oak because I didn't get a reply there, so I hope I might get one here:
>>>
>>>
>>> We have a system that migrates our sites based on migration rules, the psuedocode is as the following:
>>>
>>> resourceResolver = getServiceResourceResolver("migration-user");
>>> for(Site site in sites) {
>>> migrateSite(resourceResolver)
>>> }
>>>
>>> Everything works fine, but we would like it more performant, so the change I did was the following:
>>>
>>> resourceResolver = getServiceResourceResolver("migration-user");
>>> for(Site site in sites) {
>>> threadPool.submit(new Runnable() { run() {
>>> migrateSite(resourceResolver)
>>> });
>>> }
>>>
>>> This gave the following exception:
>>>
>>> 21.03.2019 11:32:47.244 *WARN* [sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4] org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to perform hasProperty while thread sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2 was concurrently writing to this session. Blocked until the other thread finished using this session. Please review your code to avoid concurrent use of a session.
>>>
>>> So I decided to change the code to the following:
>>>
>>> for(Site site in sites) {
>>> threadPool.submit(new Runnable() { run() {
>>> resourceResolver = getServiceResourceResolver("migration-user");
>>> migrateSite(resourceResolver)
>>> });
>>> }
>>>
>>> But it seems that the warn that is being thrown is still being thrown, does this mean that getting a new service resourceresolver based on the same user name still get into lockings / synchronizing issues? Is there any way to solve this?
>>>
>>> Thanks,
>>> Roy
>>>
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
Re: Multiple threads on same resource resolver
Posted by Michael Dürig <md...@apache.org>.
Hi,
Sorry for missing the original post on the Oak list.
Like Carsten said, sessions do not support multiple threads. See also
https://docs.adobe.com/docs/en/spec/jcr/2.0/4_Connecting.html
The warning you receive is from a protection mechanism in Oak that
prevents the worst. I.e. data corruption. However, there are no
guarantees beyond that. E.g. performance or even progress (no deadlocks).
Michael
On 28.03.19 07:32, Carsten Ziegeler wrote:
> Hi,
>
> a resource resolver is single threaded and must not be used concurrently
> by multiple threads. Main driver (but not the only one) is the JCR
> session which requires this.
>
> However, there is nothing in the Sling code base blocking you from doing
> so anyways. So we don't have any additional checks like Oak/Jackrabbit
> has. Therefore the log message you see, is initiated by Oak. I don't
> want to sent you from one list to another, but to my knowledge your
> latest code looks ok to me and I'm not aware that you can only have one
> thread for a service user. But maybe your getServiceResourceResolver
> method is always returning the same instance and not creating one per
> call? If not, I fear this is an issue for Oak.
>
>
> Regards
>
> Carsten
>
>
> Roy Teeuwen wrote
>> Hey sling users,
>>
>> This is a repost from the userlist of oak because I didn't get a reply
>> there, so I hope I might get one here:
>>
>>
>> We have a system that migrates our sites based on migration rules, the
>> psuedocode is as the following:
>>
>> resourceResolver = getServiceResourceResolver("migration-user");
>> for(Site site in sites) {
>> migrateSite(resourceResolver)
>> }
>>
>> Everything works fine, but we would like it more performant, so the
>> change I did was the following:
>>
>> resourceResolver = getServiceResourceResolver("migration-user");
>> for(Site site in sites) {
>> threadPool.submit(new Runnable() { run() {
>> migrateSite(resourceResolver)
>> });
>> }
>>
>> This gave the following exception:
>>
>> 21.03.2019 11:32:47.244 *WARN*
>> [sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4]
>> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to
>> perform hasProperty while thread
>> sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2
>> was concurrently writing to this session. Blocked until the other
>> thread finished using this session. Please review your code to avoid
>> concurrent use of a session.
>>
>> So I decided to change the code to the following:
>>
>> for(Site site in sites) {
>> threadPool.submit(new Runnable() { run() {
>> resourceResolver = getServiceResourceResolver("migration-user");
>> migrateSite(resourceResolver)
>> });
>> }
>>
>> But it seems that the warn that is being thrown is still being thrown,
>> does this mean that getting a new service resourceresolver based on
>> the same user name still get into lockings / synchronizing issues? Is
>> there any way to solve this?
>>
>> Thanks,
>> Roy
>>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: Multiple threads on same resource resolver
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
a resource resolver is single threaded and must not be used concurrently
by multiple threads. Main driver (but not the only one) is the JCR
session which requires this.
However, there is nothing in the Sling code base blocking you from doing
so anyways. So we don't have any additional checks like Oak/Jackrabbit
has. Therefore the log message you see, is initiated by Oak. I don't
want to sent you from one list to another, but to my knowledge your
latest code looks ok to me and I'm not aware that you can only have one
thread for a service user. But maybe your getServiceResourceResolver
method is always returning the same instance and not creating one per
call? If not, I fear this is an issue for Oak.
Regards
Carsten
Roy Teeuwen wrote
> Hey sling users,
>
> This is a repost from the userlist of oak because I didn't get a reply there, so I hope I might get one here:
>
>
> We have a system that migrates our sites based on migration rules, the psuedocode is as the following:
>
> resourceResolver = getServiceResourceResolver("migration-user");
> for(Site site in sites) {
> migrateSite(resourceResolver)
> }
>
> Everything works fine, but we would like it more performant, so the change I did was the following:
>
> resourceResolver = getServiceResourceResolver("migration-user");
> for(Site site in sites) {
> threadPool.submit(new Runnable() { run() {
> migrateSite(resourceResolver)
> });
> }
>
> This gave the following exception:
>
> 21.03.2019 11:32:47.244 *WARN* [sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4] org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to perform hasProperty while thread sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2 was concurrently writing to this session. Blocked until the other thread finished using this session. Please review your code to avoid concurrent use of a session.
>
> So I decided to change the code to the following:
>
> for(Site site in sites) {
> threadPool.submit(new Runnable() { run() {
> resourceResolver = getServiceResourceResolver("migration-user");
> migrateSite(resourceResolver)
> });
> }
>
> But it seems that the warn that is being thrown is still being thrown, does this mean that getting a new service resourceresolver based on the same user name still get into lockings / synchronizing issues? Is there any way to solve this?
>
> Thanks,
> Roy
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org