[
https://issues.apache.org/jira/browse/SLING-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157797#comment-14157797
]
Carsten Ziegeler commented on SLING-3984:
-----------------------------------------
We're already miles away from the original jasper as we added a lot of stuff
over time. So one more thing on top does not make a difference
> JSP Compilation failure under heavy load
> ----------------------------------------
>
> Key: SLING-3984
> URL: https://issues.apache.org/jira/browse/SLING-3984
> Project: Sling
> Issue Type: Improvement
> Components: Scripting
> Affects Versions: Scripting JSP 2.0.28
> Reporter: Viktor Adam
> Assignee: Carsten Ziegeler
> Fix For: Scripting JSP 2.1.6
>
> Attachments:
> Sling_scripting__workaround_for_concurrency_issues_when_compiling.patch
>
>
> We have seen problems with JSP compilation under heavy load. It looks like
> when multiple threads try to compile the same JSP or tag file the result can
> be NoClassDefFoundError, ClassNotFoundException or simply compilation
> failures (saying method return types not match the expected type, etc.)
> While I was investigating the issue I have found the following things:
> First: multiple wrapper instances can exist at the same time for a given JSP
> file because the caching of them (creating/storing) is not atomic. I have
> verified that multiple threads can execute the compilation inside the
> prepareServlet method at the same time. This was my initial prime suspect.
> Synchronizing access for this method didn't solve all the problems so I have
> looked into the taglib related parts as taglib related exceptions/errors
> showed up frequently in stack traces.
> Finally I've found out that the problem (for us) is around the loadTagFile
> method of the JspServletWrapper class. This method is invoked from the
> TagFileProcessor.loadTagFile method which - I believe - again, can have
> different JspServletWrapper instances for the same taglib at the same time
> and compiling them concurrently can lead to problems (so it seems). By adding
> a per-file locking around the body of this method I am no longer able to
> reproduce the compilation errors, JSP files are compiled correctly.
> I will attach a patch with my changes to the 2.0.28 version (I haven't found
> any noticeable changes around this area since) which solved the problems, for
> us at least.
> I think I may lock for a larger scope than it is absolutely necessary so
> maybe someone can advise me on this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
