On a recent upgrade from ACF to Lucee we have noticed a situation where
performance becomes an issue that we did not have on ACF.
We notice that under normal operations, our sites run very fast, faster
than they did on an equivalent machine running ACF 9.01.
Our application architecture consists of two parts, and application builder
and the applications built by the builder.
The application builder reads our standard templates (about 160 or so) into
memory and replaces various mnemonics with client-customized snippets of
codes and writes the .cfm pages to the webroot for each of our 55 sites
running on our Lucee 4.5 installation. (win 2012)
The builder can loop over all 55 clients and rewrite all the pages of those
sites in about 4 or 5 minutes.
Over the years, we have always done this throughout regular business hours
without any issue…sometimes several times a day.
In Lucee, we have found that while the application builder is running,
access to the sites comes to almost a screeching halt …taking sometimes
20, 30 or 40 seconds for pages to complete. and on some occasions the
pages timeout … with (sometimes) the following errors appearing the log
files.
java.lang.ThreadDeath
at java.lang.Thread.stop(Unknown Source)
at lucee.commons.io.StopThread.run(SystemUtil.java:1091)
Exception in thread “Thread-53889” java.lang.NullPointerException
at lucee.commons.io.StopThread.run(SystemUtil.java:1068)
Exception in thread “ajp-nio-8009-exec-14”
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.poll(Unknown Source)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:85)
at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:31)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
It does recover eventually… maybe 3 or 4 minutes after the application
builder completes, but not before someone complains of performance issues
by our clients.
I have tried all 3 settings for *Inspect Templates (CFM/CFC) *setting
(always, once, never)
The problem occurs exactly the same for always and once.
Obviously, when set to never it the issue goes away but as soon as I
click “Clear page cache Pool” to make the latest rebuild changes
persistent, the issue shows itself . This leads me to speculate that it
must have something to do with the algorithms used to populate/refresh the
cache or the comparison routine for large-scale wholesale changes in the
file timestamps?
Hate to bring up the fact that it the behavior was different in ACF but
this is something we need to be able to do a regular basis without
interference to our clients
ability to work.
Has anyone else ever had such an experience?
Any thoughts on why this happens? and what we can do about it?
