Not bad +1 for view pool. When VIEW_POOL_ENABLED the param org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is not considered and not required to set. org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION is valid for state saving client/server. Regards, Dora Rajappan.
On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <andraschko.tho...@gmail.com> wrote: Cool leo! Thanks for your effort :) 2013/12/13 Leonardo Uribe <lu4...@gmail.com> Hi > >Finally the code for View Pooling has been comitted. After some performance >tests with the know demo application, it has been confirmed the following >improvements: > >- A reduction of 25% of the transient memory used, which means a lot less >memory is used and it is used at a slower pace. It also means less GC calls >and a better CPU usage. >- An improvement of 9% over throughput for non ajax requests. >- An improvement from 9% to 30% or even more for ajax request, according to >the tree size. > >These improvements are very good and justify the use of the view pool. But >in order to be transparent and open with the community we have not explained >the details behind how the view pool really works. So, I created a blog >about this topic that I hope to move it into MyFaces documentation once >a release of 2.2.0 is out (we have some pending work to do in the >documentation area, so I hope to do everything in one step). > >http://lu4242.blogspot.com/2013/12/view-pooling-in-jsf-22-using-apache.html > >The blog summarize all information about this topic, its origins, >the reasons behind them and the solution proposed, so we can discuss it later >if there is any doubt or critic about it. It is a long story but this is >something we need to document properly. > >regards, > >Leonardo Uribe > > > > >2013/12/9 Leonardo Uribe <lu4...@gmail.com> > >Hi >> >>It seems we have an inconsistency between what was proposed to enable the >>view pool and the inclusion of the new parameter. >> >>At start we have this: >> >> >>org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in the >>app, by default false) >> >> >> >>But if we use an attribute in f:view like "oamEnableViewPool", aiming to >>select the views that will use the pool, the previous param does not look >>good because it overlaps the attribute. >> >> >>In this case, I think it is better to keep things simple and remove the web >>config param and let the pool to be enabled only through the attribute or the >>entry in faces-config-extension. I'll do that. >> >> >>regards, >> >>Leonardo Uribe >> >> >> >> >> >>2013/12/9 Thomas Andraschko <andraschko.tho...@gmail.com> >> >>Hi Leo, >>> >>>sounds fine! thanks :) >>> >>> >>> >>> >>>2013/12/9 Leonardo Uribe <lu4...@gmail.com> >>> >>>Hi >>>> >>>> >>>>I think we could add it as a parameter for f:view tag, for example call it >>>>oamEnableViewPool. The patch proposed uses already an attribute for disable >>>>the pool in some cases, but after doing some experiments (MYFACES-3831) I >>>>have found we need to change some parts of the algorithm. Specifically I >>>>have found that it is not really necessary the check to disable the pool >>>>when VariableMapper is used because with the code we have in place there >>>>is no way an EL expression should not be the same each time the view is >>>>built. >>>> >>>> >>>>A phaselistener is not necessary. I think the best place to set the param >>>>manually is ViewHandler.createView(...). >>>> >>>> >>>> >>>>regards, >>>> >>>> >>>>Leonardo Uribe >>>> >>> >> >
