Multiple threads on same resource resolver

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple threads on same resource resolver

Roy Teeuwen
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
Reply | Threaded
Open this post in threaded view
|

Re: Multiple threads on same resource resolver

Carsten Ziegeler
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
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Multiple threads on same resource resolver

Michael Dürig-3

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
> [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Multiple threads on same resource resolver

Roy Teeuwen
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 <[hidden email]> 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
>> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Multiple threads on same resource resolver

Julian Sedding-3
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 <[hidden email]> 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 <[hidden email]> 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
> >> [hidden email]
>