[ https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14934787#comment-14934787 ]
Dirk Rudolph edited comment on SLING-5068 at 9/29/15 7:34 AM: -------------------------------------------------------------- I can confirm that the solution is working for my use case. Many thanks [~cziegeler] was (Author: diru): I can confirm that the solution is working or my use case. Many thanks [~cziegeler] > 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-2.patch, 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)