sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Viktor Adam (JIRA)" <>
Subject [jira] [Commented] (SLING-3984) JSP Compilation failure under heavy load
Date Mon, 03 Nov 2014 09:57:34 GMT


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:
>             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
> 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

View raw message