[
https://issues.apache.org/jira/browse/SLING-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14154739#comment-14154739
]
Viktor Adam commented on SLING-3984:
------------------------------------
Yes, the wrapper only existed once in the ConcurrentHashMap at the end, but the
same JSP file could have different wrappers at the same time and be compiled on
multiple threads.
To reproduce, I've used an access.log from our server and replayed the requests
to Sling when the JSP cache was empty. To do this, I have deleted the compiled
classes and gave the bundle a restart (just to drop any in-memory cached
classes) and then started hitting the server (in our case, doing this on 15
different threads was enough). I think it should be relatively easy to
reproduce the issue if you have several JSPs including other JSPs and tag files
then hitting them simultaneously (forcing them to start compiling at the same
time but on different threads).
> 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
> 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)
