[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14933875#comment-14933875
]
Dirk Rudolph edited comment on SLING-5068 at 9/28/15 8:52 PM:
--------------------------------------------------------------
Makes sense. It reduces the overhead of having a per thread copy of the
Resource in Heap for each of the ScriptResource objects.
was (Author: diru):
Isn't that exactly the same as the solution I proposed? I mean the
ScriptResource gets instantiated with the perThreadScriptResolver anyway (via
the passed Resource). The only advantage I see is that the sharedResource is
not ThreadLocal but volatile. Honestly I would prefer my solution because the
amount of Threads is limited by a ThreadPool anyway and we don't need to
introduce a volatile member.
Anyway in most cases sharedResource is returned so I would write an early
return for sharedResource at the early beginning of getActiveResource();
> 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)
