We are running AEM 5.6.1.20130606 and getting sporadic warnings on concurrent access of JCR sessions.
The warnings seem be coming from com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter. This filter is a part of the com.day.cq.wcm.cq-wcm-mobile-core bundle. Our version is 5.6.2.
A common pattern from our logs:
02.08.2016 17:01:52.373 *DEBUG* [10.111.2.223 [1470171712320] GET /content/research/an-introduction-to-twitter.html HTTP/1.1] org.apache.jackrabbit.core.session.SessionState Attempt to perform item.getPath() while another thread is concurrently reading from session-admin-411. Blocking until the other thread is finished using this session. Please review your code to avoid concurrent use of a session. java.lang.Exception: Stack trace of concurrent access to session-admin-411 at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:185) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:376) at org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.<init>(JcrNodeResource.java:90) at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.createResource(JcrResourceProvider.java:195) at org.apache.sling.jcr.resource.internal.helper.jcr.JcrResourceProvider.getResource(JcrResourceProvider.java:134) at org.apache.sling.resourceresolver.impl.tree.ResourceProviderFactoryHandler.getResource(ResourceProviderFactoryHandler.java:107) at org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResourceFromProviders(ResourceProviderEntry.java:382) at org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getInternalResource(ResourceProviderEntry.java:345) at org.apache.sling.resourceresolver.impl.tree.ResourceProviderEntry.getResource(ResourceProviderEntry.java:131) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResourceInternal(ResourceResolverImpl.java:934) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:570) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getResource(ResourceResolverImpl.java:581) at org.apache.sling.resourceresolver.impl.helper.ResourceResolverContext.getParentResourceType(ResourceResolverContext.java:218) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.getParentResourceType(ResourceResolverImpl.java:1136) at org.apache.sling.resourceresolver.impl.ResourceResolverImpl.isResourceType(ResourceResolverImpl.java:1156) at org.apache.sling.api.resource.ResourceUtil.isA(ResourceUtil.java:466) at com.day.cq.wcm.mobile.core.MobileUtil.isMobileResource(MobileUtil.java:159) at com.day.cq.wcm.mobile.core.MobileUtil.isMobileResource(MobileUtil.java:131) at com.day.cq.wcm.mobile.core.impl.redirect.RedirectFilter.doFilter(RedirectFilter.java:216) ....
I looked at RedirectFilter in the debugger and indeed, there is a instance-level variable adminResolver which is instantiated in @Activate and shared in every call of doFilter().
It does not smell right to me. A Jackrabbit session acquires the exclusive lock for accessing its state which means other threads have to wait until RedirectFilter finishes using adminResolver. Correct me if I'm wrong, but this is a potential scalability issue.
