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
cziege...@apache.org