[jira] [Closed] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carsten Ziegeler closed SLING-5068.
-----------------------------------

> 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)