Viktor Adam created SLING-3984:
----------------------------------
Summary: 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
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)
