[@All] Mojarra Important Perfomance Problems

[tandraschko]

I think this just demostrate the rendering/build view performance. For exmaple, as already said in this post: on postback's, myfaces is much faster.
But as stated in the mailing list, this solution isn't perfect.

[KingdomHeart]

Also as Thomas point previously, Stateless JSF is now for Mojarra, and that there are quite some works need to be done to make Stateless fast in MyFaces. Here is his link in previous page

http://comments.gmane.org/gmane.comp.ja ... evel/54352

[smithh032772]

I think this just demostrate the rendering/build view performance. For exmaple, as already said in this post: on postback's, myfaces is much faster.
But as stated in the mailing list, this solution isn't perfect.

Thanks for this response. This shows that I can stay with Mojarra, but I did recognize some strange 'AJAX' behavior with my environment (see my signature below) when users are concurrently accessing the app (and/or same data). I'll be doing more of concurrent user testing soon.

[tandraschko]

and that there are quite some works need to be done to make Stateless fast in MyFaces.

As i understand correclty: The part, which is faster with stateless mode, is already very fast in myfaces. So the improvment in Mojarra is more then with MyFaces.

[Aditya]

If you would like to see Stateless extension getting added to MyFaces, you all can vote for this proposal to add Stateless extension to MyFaces project.

Also, for discussing about the compatibility issues with respect to existing JSF infrastructure when using Stateless extension for Mojarra, I created a new Topic Stateless JSF & Primefaces compatibility

[kidvid]

The ticket mentioned in the original thread was closed, but we made a new ticket. It's a real problem, but you need a really large page in order to really demonstrate it, as shown in the example attached to the following Java Server Faces ticket:

http://java.net/jira/browse/JAVASERVERFACES-2494

The problem is the way that Mojarra finds nodes in the DOM after you submit an AJAX request for a partial page update. If you have a very large HTML tree, say 10k nodes, then every time you do an ajax request, it searches through all 10k nodes, very very inefficiently. They really need to restructure their code using hashmap searching, or something equivalent, instead of crawling through the HTML tree structure.

[tandraschko]

This isn't only JS side. Also processing @ server was/is very slow compared with MyFaces.

[javaone9]

Our JSF app runs out of memory and gets OutOfMemory error quite often when the number of users increases or visited by search engines that starts a new session for every GET. JSF Stateless will solve this memory issue. I VOTE for JSF Stateless feature. Our JSF facelets do not use <c>, all pages are static, can I use the feature with mojarra 2.1.7 now? IF not in Mojarra release, where to download?

Thanks
Dave

[cagatay.civici]

What does stack trace or profiler hint on outofmemory? Haven't you tested your app with a profiler for concurrent users?

[smithh032772]

JSF Stateless will solve this memory issue. I VOTE for JSF Stateless feature. Our JSF facelets do not use <c>, all pages are static, can I use the feature with mojarra 2.1.7 now? IF not in Mojarra release, where to download?

1. did you read this entire conversation?
2. from what I remember, someone mentioned that JSF stateless works with Mojarra 2.1.3
3. MyFaces 2.1.7, 2.1.8, 2.1.9, 2.1.10 may resolve this issue
4. search google/stackoverflow.com for number of sessions web.xml
5. when asking question, please provide stacktrace of your exception (as Cagatay/Prime asked for already, above)