Thank you very much, Vicente. I've only just added a comment with some
infos.
Let's wait and see how they will react to it.
cu
Jens
Am 02.11.2023 um 13:49 schrieb Vicente Rossello:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68054
Let's see how it works
On Tue, Oct 31, 2023 at 3:04 PM Vicente Rossello <cocorosse...@gmail.com>
wrote:
I will try to open a bug. An obvious fix is to only make 1 call to
getCannonicalPath for the same file. That would halve the time.
After that I guess is tomcat team decission.... maybe emitting a warning
that allowLinking=false in windows is very slow for jsf development ... or
they may have more ideas
El mar, 31 oct 2023, 14:20, Jens Zurawski <j...@diegurus.de> escribió:
Ok, after 4 hours of bisecting, checking out, building and testing (I've
needed three bisect sessions, because the first one wasn't successful
due to build failures of some revisions and I had to manually find some
other revisions to bisect) I can definitely identify the commit which
introduces the DevMode performance issue. It is:
0325d91 TOMEE-3773 - Update Tomcat to 9.0.50
I've cross checked with the immediate commit before (277fc71) and it's
clear:
277fc71 good
0325d91 bad
So, indeed, tomcat is the root cause of the problem. But, I don't think
it will be successful to create an issue in tomcat. A far as I can see
in the diffs of tomcat 9.0.48 to 9.0.50, I assume, it already was a bug
fix in /java/org/apache/catalina/webresources/DirResourceSet.java. In
that class new code was inserted to skip symbolic links in
ServletContext.getResourcePaths(), which, I think, is important as a
security measure. Therefore, most likely they will not be willing to
revert that (I wouldn't recommend that, either)
Long story short: It's not a bug it's a feature ;-)
I guess, JSF in DevMode is doing a lot more calls to getResourcePaths()
hence suffering from this fix. Because ProdMode is not affected by this
I can live with it. Development environments are special in any case,
and to allow the dev tomcat following symlinks in that environment is
ok, from my pov. Just enable the allowLinking="true" and it works.
At least my "academic problem" is solved and my "inner monk" is
satisfied and I don't think I will walk down this route any further.
Many thanks to all of you who have helped me on this issue.
cu
Jens
Am 28.10.2023 um 15:17 schrieb Jens Zurawski:
Yes, this may be one of the next steps here. But, I'm afraid, I have
not enough info for them right now.
Neither do I have a small test case to reproduce the problem, nor can
I point them exact enough to what the problem might be. Also, maybe
it's only coincidence, and the real problem is somewhere inside
myfaces. The fact that ProdMode is not affected at all (at least not
enough to measure any difference) and it only arises in JSF DevMode
could point in that direction.
So, before I go and open an issue on Tomcat, I want to try to narrow
down it more. At least to the point where I can say: look, this commit
in TomEE introduced it. And even better: here is a small test case to
reproduce it.
cu
Jens
Am 28.10.2023 um 12:55 schrieb Richard Zowalla:
Cool. Thanks for going down the rabbit hole ;-)
Given that there is a lot of information/benchmarks etc. collected in
this thread, what do you think about opening an issue in Tomcat with
a reference to this thread?
They might take a look.
Gruß
Richard
Am 28. Oktober 2023 12:22:12 MESZ schrieb Jens Zurawski
<j...@diegurus.de>:
For all who are interested I've made some quick benchmarks, to see
the impact.
I've taken one of my biggest views which is making a small AJAX poll
on the same view every 30s to be able to get some balanced average
values for the response times. The payload of the poll is small
(around 500 to 1000 bytes) but because it's the same view, the
component tree is big.
Windows (same machine localhost, it is an 8 core Ryzen-7 with 64GB
of RAM and SSD, so the machine is not the limiting factor)
====================================================
~ 12000 ms DevMode plain
~ 600 ms DevMode with <Resources archiveIndexStrategy="bloom"
allowLinking="true"/>
~ 100 ms ProdMode plain
~ 100 ms ProdMode with <Resources archiveIndexStrategy="bloom"
allowLinking="true"/>
Linux (customer site over Internet VPN, it is a 6 core Intel i5 with
16GB of RAM and SSD)
====================================================
~ 700 ms DevMode plain
~ 350 ms DevMode with <Resources archiveIndexStrategy="bloom"
allowLinking="true"/>
~ 130 ms ProdMode plain
~ 130 ms ProdMode with <Resources archiveIndexStrategy="bloom"
allowLinking="true"/>
No, the 12000 ms is _not_ a typo ;-)
My conclusions from these figures are:
- ProdMode is not affected by this issue
- On Windows the problem is very significant and renders the DevMode
unusable
- On Linux the problem is not that dramatic, so one can say "well,
it's dev mode, deal with it", but it is also affected in doubling
the response times. Maybe worth enough to also look into this issue
even if one is Linux only.
cu
Jens
Am 28.10.2023 um 11:43 schrieb Jens Zurawski:
I can confirm, that this setting also solves the problem of the
slow dev mode. Thank you for the tip.
So, either this or the canonCache solves this issue for me on my
development environment. But, of course, both of them should be
avoided on production systems. The chances that they slip from dev
to prod by accident may be small (if one is using well known "good"
development strategies and methods, like staging, testing Q&A,
reviews, and the like) but still possible.
And the fact, that it seems to only really matter in JSF dev mode
is curious at the least.
Am 28.10.2023 um 08:24 schrieb Vicente Rossello:
Sorry, that was not correct.
The allowLinking is at the resources level. So, in the
META-INF/context.xml
file:
<?xml version="1.0" encoding="UTF-8"?>
<Context allowCasualMultipartParsing="true" reloadable="false"
containerSciFilter="org.apache.tomcat.websocket.server.WsSci|org.apache.jasper.servlet.JasperInitializer"
parallelAnnotationScanning="true"
clearReferencesThreadLocals="false"
skipMemoryLeakChecksOnJvmShutdown="true">
<Manager pathname=""/>
<Resources archiveIndexStrategy="bloom" allowLinking="true"/>
</Context>
BTW, the slowness is something between checking the canonicalPath
too
many times and jdk12 that removed those canonCache by default. See
https://bugs.openjdk.org/browse/JDK-8258036
