[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933565#comment-14933565
]
Carsten Ziegeler commented on SLING-5068:
-----------------------------------------
Thanks for the patch, I think it does the trick.
But :) I'm wondering if we could change this a little bit: right now the shared
RR is used for every thread which is not the original thread - which means in
most of the cases. I think if we pass in the thread local from the script
resolver, we can in almost all cases use the per thread resolver, reducing the
contention on the shared one. WDYT?
> perThreadScriptResolver is shared between multiple Threads causing ISE in
> ResourceResolverImpl
> ----------------------------------------------------------------------------------------------
>
> Key: SLING-5068
> URL: https://issues.apache.org/jira/browse/SLING-5068
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: Servlets Resolver 2.3.6
> Environment: We are facing the following issue with AEM 6.1 build on
> top of Servlet Resolver 2.3.6.
> Reporter: Dirk Rudolph
> Assignee: Carsten Ziegeler
> Priority: Critical
> Fix For: Servlets Resolver 2.3.8
>
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt,
> sling-5068.patch
>
>
> We are building a single page application that loads small markup pieces in
> several subsequent requests. For each request the same rendering applies and
> so the same script is used.
> When cleaning the ServletResolvers internal cache we get a lot of ISE
> ("Resource resolver is already closed") which seems to be because the
> ResourceResolver is used in multiple Threads.
> The problem seems to be that the first request creates an entry in the
> servlet resolvers cache with a servlet that sets the perThreadScriptResolver
> of this request/thread to the context. This entry is reused in another
> thread. When now the first one finishes the processing the
> perThreadScriptResolver gets closed in the onEvent method of ServletResolver
> but is still used in the ScriptContext of another Thread.
> See the attached Exceptions we got by adding some trace logging to the
> ResourceResolverImpl (1.2.4). It proves that it is the
> perThreadScriptResolver and not the shared one that causes the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
