[ https://issues.apache.org/jira/browse/SLING-3984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194398#comment-14194398 ]
Viktor Adam commented on SLING-3984: ------------------------------------ [~cziegeler] We've had a few deployment since my last update and we haven't had this problem so I think you can close this ticket. Thank you for your help! > 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, > jsp_exception.stacktraces.zip > > > 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)