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