Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002759 [Resin] minor always 06-30-08 16:16 07-06-08 19:30
Reporter ferg View Status public  
Assigned To ferg
Priority urgent Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 3.2.0 Product Version 3.1.6
  Product Build
Summary 0002759: reduce jsp synchronization lock
Description (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.
 
Steps To Reproduce
Additional Information
Attached Files

- Relationships

- Notes
(0003231)
ferg
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 MakeContainer.java. 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.
 

- Issue History
Date Modified Username Field Change
06-30-08 16:16 ferg New Issue
07-01-08 10:39 ferg Note Added: 0003231
07-06-08 19:30 ferg Assigned To  => ferg
07-06-08 19:30 ferg Status new => closed
07-06-08 19:30 ferg Resolution open => fixed
07-06-08 19:30 ferg Fixed in Version  => 3.2.0


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
28 total queries executed.
25 unique queries executed.
Powered by Mantis Bugtracker