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

Hi Vicente,

thank you for the tip. This is a good workaround. When I switch to 
Production mode and insert this configuration, it reloads the view from 
the file if it has changed. This means, I can use a decent version of 
TomEE in my dev environment.

However, it doesn't completely solve my problem, as the error reporting 
isn't as verbose as in Dev mode as far as I can see. But I have to 
check, maybe it's enough for my development.

And, well.... the academic problem: "Why is it still broken in Dev 
mode?" still runs circles through my brain ;-) Because if it's a problem 
of my coding, it might be a good idea to change this, before it might 
get a problem on Production mode, too, at some time in the future.

But anyway, you've helped me a good step forward, thanks.
cu
Jens


Am 26.10.2023 um 17:04 schrieb Vicente Rossello:
> We are using the production stage with javax.faces.FACELETS_REFRESH_PERIOD
> = 1. It's faster and more similar to production, just try it if it solves
> your problem
>
> On Thu, Oct 26, 2023 at 4:18 PM Jens Zurawski <[email protected]> wrote:
>
>> The one bundled with TomEE.
>> myfaces 2.3.7 on TomEE 8.0.6
>> and  e.g. myfaces 2.3.9 on TomEE 8.0.12
>>
>> Am 26.10.2023 um 16:08 schrieb Richard Zowalla:
>>> Which JSF lib are you using?
>>>
>>> Am 26. Oktober 2023 16:00:57 MESZ schrieb Jens Zurawski <[email protected]
>>> :
>>>> Thank you for your quick reply, Jonathan.
>>>>
>>>> It is good to know, that normally the Dev mode should work as fast as
>> before even with 8.0.15. So it obviously has something to do with my
>> environment, configuration and/or code.
>>>> And also thank you for the reference to tomitribe. Unfortunately I'm
>> the only developer on this project, and it will be difficult to convince my
>> customer to an additional support subscription, because he on production
>> doesn't have issues ;-) But, ok, that's my problem, and maybe I'll consult
>> tomitribe in the future for other projects.
>>>> So, I'm afraid, for the near future I'm on my own to solve this
>> problem. Therefore any hints to restrict the places where I should take a
>> look will be more than welcome.
>>>> I'm a senior programmer with 20 years of experience in Java programming
>> (SE and JSP). But I'm relative new to JSF/JavaEE/JakartaEE and sometimes I
>> have a hard time to understand which component of the whole stack is
>> responsible for what.
>>>> The project meanwhile has over a 1/4 million lines of code (most of
>> them in the back-end, but also the front-end is big enough to not trace
>> through every lane if I want to get to the point in this life :-D ).
>>>> The application now runs for nearly 2 years on the customers site and
>> is very reliable and fast in its daily usage. Apart from occasional updates
>> every few month, it will never be restarted or need any manual maintenance
>> at all. So I assume the code is not the badest on earth. At least because
>> of that I'm able to out-rule things like memory leaks, gc issues or
>> bottlenecks (max Heap is never reached, neither half of it, even after
>> running for month).
>>>> Of course there could be aspects of JSF which I may not have understood
>> correctly until now. But because there are so many new things to a JSF
>> beginner like me, I'm running out of ideas what this could be. It is
>> something that worked well 'til TomEE 8.0.6 (Prod and Dev mode) and
>> suddenly don't work anymore on 8.0.12 in Dev mode (but still works great in
>> Prod mode). There are only minor versions in-between. So I think there were
>> no revolutionary changes anywhere. My hope was (and still is), that anybody
>> here on the list might have had a similar problem and has solved it, or
>> maybe someone knows about some changes in Dev mode which could explain such
>> behaviour (don't know, maybe xml parsing or component tree generation has
>> changed, or scope handling of managed beans, or whatever could cause some
>> code to be entered far more often than before, or some cache/pool was
>> removed or has different behaviour... such things). Then it would be far
>> more easy for me to track down the real problem.
>>>> Anyway, when I get some spare time (currently have some deadlines in
>> sight), I'll try to build a small test case. Either I can get a grip on the
>> issue myself on doing this, or I can supply it to anyone who might want to
>> have a look at it.
>>>> cu
>>>> Jens
>>>>
>>>>
>>>>
>>>> Am 26.10.2023 um 14:01 schrieb Jonathan S. Fisher:
>>>>>> newer versions are so incredibly slow in dev mode
>>>>> I can assure you that Dev/Prod mode works very very swiftly on 8.0.15
>>>>> for sizable applications. For example, I have a giant application
>>>>> (thousands of LOC, 50+ jsf views) that has sub-8ms response times
>>>>> (minus database time). More than likely they are doing something they
>>>>> should not be doing with JSF apis and are causing problems.
>>>>>
>>>>> I would check the obvious things first with VisualVM: heap size, gc
>>>>> frequency, etc. You can also run their profiler and see if you can
>>>>> spot anything immediately obvious.
>>>>>
>>>>> After that, the easiest way to locate the code slowing you down is
>>>>> bisection. Cut half the code out, run, and continue cutting until you
>>>>> can locate the problematic code. Then after that, isolate a test case
>>>>> where flipping a boolean flag triggers the issue and post the results
>>>>> here.
>>>>>
>>>>> I would get ahold of: https://www.tomitribe.com who are literal
>>>>> experts in this stuff. They offer professional services to handle
>>>>> exactly these situations and can work directly in your codebase to
>>>>> help you find and fix the problem.
>>>>>
>>>>> On Thu, Oct 26, 2023 at 5:48 AM Jens Zurawski <[email protected]> wrote:
>>>>>> Hi altogether,
>>>>>>
>>>>>> I'm new to this list and hope it's the right place to ask this
>> question.
>>>>>> If not, and someone know the right place to ask this, please give
>> advise.
>>>>>> I'm developing a big JSF Application for a customer. It's a long
>> running
>>>>>> project and development and when I started with it, TomEE 8.0.6 was
>> the
>>>>>> most recent Version of TomEE. The switch to Jakarta is planned for
>> next
>>>>>> year, so I'm still on the 8.x path for the time being and wasn't able
>> to
>>>>>> test if this problem still exists in the 9.x branch.
>>>>>>
>>>>>> The problem:
>>>>>> On the customers site I'm with the latest TomEE version 8.0.15
>> (running
>>>>>> on Java 11) and everything works fine, because it is running in
>>>>>> production mode. But in my development environment I'm still stuck
>> with
>>>>>> 8.0.6, because there I need the development mode
>>>>>> (javax.faces.PROJECT_STAGE: Development). I need to be able to see
>>>>>> changes in facelets without restarting everything everytime, and to
>> get
>>>>>> more detailed error messages.
>>>>>> My attempts to update my dev TomEE to something newer than 8.0.6 all
>>>>>> failed, because all (at least all I've tested so far) newer versions
>> are
>>>>>> so incredibly slow in dev mode, that it's unbearable to use the
>>>>>> application. Several very looong seconds on every request (even the
>>>>>> little AJAX requests in a view) is simply not a practical environment.
>>>>>> After switching to Production mode everything works very fast, and all
>>>>>> my views have response times of very few ms (even the big ones with
>> max.
>>>>>> around 400ms). When switching back to Development mode I have response
>>>>>> times of up to 30s on big views. Not with 8.0.6, there even in
>>>>>> development mode it's reasonable fast in not getting higher than 1s.
>>>>>>
>>>>>> My question:
>>>>>> What causes this enormous performance degradation? I'm hoping, it is
>>>>>> just a configuration which now has another default value or the like.
>> If
>>>>>> yes, maybe someone can point me in the right direction of where to
>> find
>>>>>> this configuration? If it's not a configuration thing: what can I do
>> to
>>>>>> get around this?
>>>>>>
>>>>>> I haven't tested all Versions of TomEE from 8.0.6 to 8.0.15, so I
>> can't
>>>>>> say at what version exactly this behaviour changes. If it helps or is
>>>>>> needed, I can make some tests to find the exact version where this
>>>>>> happens. Versions I've already tested are: 8.0.12, 8.0.13 and 8.0.15.
>>>>>> All of them are very slow in dev mode. If you need more information,
>>>>>> I'll try to provide it.
>>>>>>
>>>>>> Thanks in advance for any help
>>>>>> cu
>>>>>> Jens
>>>>>>
>>>>>>
>> --
>> jens zurawski
>> diegurus - zurawski zurawski poppl rohland GbR
>> juister straße 3
>> 65199 wiesbaden
>>
>> kaspersweg 7b
>> 26131 oldenburg
>>
>> internet http://www.diegurus.de
>>
>> tel +49(0)611 72437966
>>
>>
>> CONFIDENTIALITY NOTICE: This e-mail message is intended only for the
>> person or entity to which it is addressed and may contain confidential
>> and/or privileged material. Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient,
>> please contact the sender by reply e-mail and destroy all copies of the
>> original message.  If you are the intended recipient but do not wish to
>> receive communications through this medium, please so advise the sender
>> immediately.
>>
>>

-- 
jens zurawski
diegurus - zurawski zurawski poppl rohland GbR
juister straße 3
65199 wiesbaden

kaspersweg 7b
26131 oldenburg

internet http://www.diegurus.de

tel +49(0)611 72437966


CONFIDENTIALITY NOTICE: This e-mail message is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.  If you are the intended recipient but do not wish to
receive communications through this medium, please so advise the sender
immediately.