[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934787#comment-14934787
]
Dirk Rudolph commented on SLING-5068:
-
I can confirm that the solution is working or my use case.
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934973#comment-14934973
]
Carsten Ziegeler commented on SLING-5068:
-
Thanks, so I'll set this to resolved now :)
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14934662#comment-14934662
]
Carsten Ziegeler commented on SLING-5068:
-
Ok, I've committed this version. I'll keep this issue open a little bit to
gather potential additional feedback
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933875#comment-14933875
]
Dirk Rudolph commented on SLING-5068:
-
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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933434#comment-14933434
]
Carsten Ziegeler commented on SLING-5068:
-
Lets assume, the servlet was created in Thread A, then the thread local in the
ScriptResource contains a value for Thread A.
Therefore if now thread B hits that servlet, the thread local returns null and
it switches to the shared one.
A simple test would be to pass in the perThreadScriptResolver thread local from
the SlingServletResolver to the ScriptResource and use that one
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933367#comment-14933367
]
Dirk Rudolph commented on SLING-5068:
-
I agree. But do we have access to ScriptContext/Bindings somewhere else? From
architectural point of view it makes sense to set "servlet resolution specific"
bindings after servlet resolution.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933401#comment-14933401
]
Dirk Rudolph commented on SLING-5068:
-
This is already done with the ScriptResource in
SlingServletResolver#getServlet(). But the returned Servlet is shared between
threads.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933325#comment-14933325
]
Dirk Rudolph commented on SLING-5068:
-
[~cziegeler]: What about implementing a special case for get() of this
attribute which then consumes a WeakReference instead of hard reference? When
the reference disappears we can easily get the shared RR from the script
resource by calling getResourceResolver again?
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1494#comment-1494
]
Dirk Rudolph commented on SLING-5068:
-
Did you mean "not set to the per thread resource resolver"? Because currently,
as far as I understood this its set the the per thread resource resolver which
is then closed by another thread. So it should be the shared one in each case?
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1498#comment-1498
]
Carsten Ziegeler commented on SLING-5068:
-
The DefaultSlingScript has no access to the per thread RR - as far as I know. I
think we could maybe solve this by setting the request attribute directly when
the servlet gets resolved for a request and let it stay there instead of
setting it in DefaultSlingScript
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933394#comment-14933394
]
Carsten Ziegeler commented on SLING-5068:
-
Ah right, it's a context attribute not a request attribute. So it might get
tricky.
The first idea which comes to my mind is:
When a servlet resource is resolved, we wrap the resource before it gets
adapted to a servlet, this way we can control what is returned as
getResourceResolver from that resource.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933414#comment-14933414
]
Carsten Ziegeler commented on SLING-5068:
-
Ah, right - I start to remember this stuff :)
The problem is that this resource - while using a thread local - is not using
the same thread local as SlingServletResolver, therefore as soon as another
thread is using this resource, the thread local will return null and it
switches to the shared resource resolver
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933363#comment-14933363
]
Carsten Ziegeler commented on SLING-5068:
-
If I see it correctly, this is what happens:
- first request for servlet A comes in, servlet A gets instanciated with the
per thread RR of that thread
- for that request ATTR_SCRIPT_RESOURCE_RESOLVER is set to the per threat RR
- for every other request, ATTR_SCRIPT_RESOURCE_RESOLVER is set to exactly that
per threat RR as well
If we move setting ATTR_SCRIPT_RESOURCE_RESOLVER out of the DefaultSlingScript
(which is shared singleton) we can set it to the correct per thread RR on each
request. I hope I did not overlook the something
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933447#comment-14933447
]
Dirk Rudolph commented on SLING-5068:
-
Currently there is no ThreadLocal in ScriptResource.
So you suggest to instead of using a WeakReference we use a ThreadLoacel to
refer to the perThreadScriptResolver and in case it is not set we return the
shared one. Sounds good, will give it a try.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933476#comment-14933476
]
Carsten Ziegeler commented on SLING-5068:
-
Sounds like a solution
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933328#comment-14933328
]
Carsten Ziegeler commented on SLING-5068:
-
We somehow have to make sure that ATTR_SCRIPT_RESOURCE_RESOLVER is set to the
per thread resource resolver
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933480#comment-14933480
]
Dirk Rudolph commented on SLING-5068:
-
Works with a small modification. Because of thread reuse (I guess) there has
been a resource in the ThreadLocal which had the perThreadScriptResolver which
was closed by a already finished request (some minutes ago). So I checked both
existence and state of the ResourceResolver.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933320#comment-14933320
]
Carsten Ziegeler commented on SLING-5068:
-
Yes, thanks - I was just further looking into the code and stumbled across
ATTR_SCRIPT_RESOURCE_RESOLVER which seems really to be the problematic part.
Not sure yet how we can solve this
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933381#comment-14933381
]
Dirk Rudolph commented on SLING-5068:
-
A simple workaround is setting the SlingServletResolver cache size to 0. But
keep in mind that there will be noticeable performance decrease.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933420#comment-14933420
]
Dirk Rudolph commented on SLING-5068:
-
Yes. In case the perThreadScriptResolver is null (WeakReference disappeared) or
not alive anymore the shared one is returned by getResourceResolver(). Thats
why is suggested to use the same approach for the attribute in the
ScriptContext itself.
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933822#comment-14933822
]
Carsten Ziegeler commented on SLING-5068:
-
I've attached an alternative patch - not sure if it is the best solution though
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933304#comment-14933304
]
Carsten Ziegeler commented on SLING-5068:
-
Looking at the code, I currently fail where this could happen within the
resolving. Would it be possible to attach a test?
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
[jira] [Commented] (SLING-5068) perThreadScriptResolver is shared between multiple Threads causing ISE in ResourceResolverImpl
[
https://issues.apache.org/jira/browse/SLING-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14933314#comment-14933314
]
Dirk Rudolph commented on SLING-5068:
-
I will have a look how to implement an integration test for that. Unfortunately
I think it will not be possible to reproduce this with an Unit test.
Think about the following timeline:
1) Request A calls resolution of Servlet A with ScriptResource using
ResourceResolver (clone of shared RR) of Request A
2) Request B calls resolution of Servlet A and gets the cached one from 1)
because Request A is still processed
3) Request B sets ATTR_SCRIPT_RESOURCE_RESOLVER of ScriptContext to
ResourceResolver of scriptResource which is the ResourceResolver of Request A
4) Request A finishes and RR cloned from shared RR gets closed
5) Request B accesses ATTR_SCRIPT_RESOURCE_RESOLVER stored in ScriptContext =>
Exception
> 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 facing the following issue with AEM 6.1 build on top
> of Servlet Resolver 2.3.6.
>Reporter: Dirk Rudolph
>Priority: Critical
> Attachments: error-stacktrace.txt, opened-and-closed-trace.txt
>
>
> 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)
