Mantis - Resin
Viewing Issue Advanced Details
2759 minor always 06-30-08 16:16 07-06-08 19:30
closed 3.1.6  
none 3.2.0  
0002759: reduce jsp synchronization lock
(rep by Sri Satish)

We are running into an issue with concurrency of Resin (a giant synchronized block that causes locks to be held long during JSP Compilation phase) at one of our field deployments.
And will appreciate help if you can direct me to someone on your team who can advise, so that the changes we are proposing that would help the performance to scale will not have any side-effects to the server logic.

07-01-08 10:39   
Here is a description of what I'm seeing. Please let me know if additional information would
be helpful.
I've hit at least two multicore scalability issues in the Resin framework regarding JSP
compilation. Relevant source code below. These snippets are from 3.0.24, which is currently
what our customer is using.
The first is for classes that are not precompiled; the JavaCompiler compile and batch compile
methods do their work under a big synchronized block. This means that when multiple clients
hit pages which need to be compiled, only one gets worked on at a time. I discovered this
during experimentation while trying to reproduce the customer problem in our lab with a
synthetic test.
The actual customer problem I was trying to reproduce is with Here, a big
global lock triggers a lock-caravan of threads piling up to enter the synchronized make method.
Make is implemented by CompilingLoader, which does an expensive and recursive (and therefore
potentially unbounded) call to findAllModifiedClasses() within the global lock.
The effect of the above is to force all compiling and evaluation of whether compiling is necessary
on one core, leaving N-1 cores (where N is hundreds on an Azul system) idle and blocked on the
single core.