Re: Very slow JSF Development Mode on tomee 8.x newer than 8.0.6

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 <[email protected]>
> 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 <[email protected]> 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
>>>>> <[email protected]>:
>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>