[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933635#comment-14933635
]
Dirk Rudolph commented on SLING-5068:
-------------------------------------
The problem I see is, that the Servlet is cached globally and therefor the
ScriptResource as well. So we have to change the cache to only cache the Path
of the Resource and get the Resource from the perThreadScriptResolver each
time. I have no idea how much this will impact the resolution performance.
Additionally its not ThreadLocal but "RequestLocal" cause of potential Thread
reuse depending on the (configuration of) the servlet container used.
WDYT, would it make sense to cache the Servlet resource path only and adapt the
Resource returned from preThreadScriptResolver to Servlet each time?
> 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)
