myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dora Rajappan <dorarajap...@yahoo.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Mon, 16 Dec 2013 17:08:41 GMT
 
Thanks for explaining viewpool and viewstate. I will go through the code later and understand.
I was wondering what happens when state saving method param is not set. I got your point it
that the state saving algorithm is performed and when its not mentioned whether it state saving
method is client/server its assumed to save views in session and that might not have changed
with view pool else it can affect maximum sequential views in session. I  have to go through
the code to follow that. 
 
Regards,
Dora Rajappan.



On Saturday, December 14, 2013 3:53 AM, Leonardo Uribe <lu4242@gmail.com> wrote:
  
Hi

"... When views are not transient and view pool enabled with no state saving or serialisation
enabled ..." 


I don't get anything about what you mean. But I understand that the topic of state management
is really, really complex, and has been a misunderstood problem for years in the world of
web application development. So I'm going to clarify your confusion:

1. If the view is "transient" then the view is considered "stateless". No state saving is
performed over stateless views, but since the view pool reuses state saving algorithm the
view is not reused by the view pool algorithm.
2. If the view is not "transient", state saving algorithm is performed.
3. You CAN'T disable state saving. There is no web config parameter to do that, not to mention
that a param to do that would be completely pointless, because the whole point of JSF is solve
with the state problem to make applications in the web easier. 

4. StateManagementStrategy deals with the problem of how the vdl calculates the state, but
it is not responsible of store the state. 
5. ResponseStateManger deals with two problems.

- Restore and save the state somewhere. In myfaces we included some classes for that: org.apache.myfaces.application.StateCacheFactory,
org.apache.myfaces.application.StateCache. There are two basic implementations: ServerSideStateCacheImpl
and ClientSideStateCacheImpl, but it can be more and it has been proposed to include a mixed
mode. There is still work and some discussions to do in that part but they are not prioritary
for now, but in the past it has been a controversial matter. The solution we have right now
works just fine.

- Modify the response to include the necessary information to save and restore the state.
This is done usually writing the javax.faces.ViewState and the javax.faces.ClientWindow.
6. StateManagementStrategy is affected by the view pool because in the calculation step we
store or retrieve a view from the pool, but ResponseStateManger is not affected by the pool.
Take a look at the code first.

regards,

Leonardo Uribe






2013/12/13 Dora Rajappan <dorarajappan@yahoo.com>

 
>Hi Leonardo,
> 
> Thanks for explaining that the statemanagementstrategy is unaffected by the view pooling.

> When views are not transient and view pool enabled with no state saving or serialisation
enabled, the view pool processing remain the same and the state is saved in session. 
>  
>Regards
>Dora Rajappan.
>
>
>
>On Friday, December 13, 2013 8:17 PM, Leonardo Uribe <lu4242@gmail.com> wrote:
>  
>Hi
>
>
>
>2013/12/13 Dora Rajappan <dorarajappan@yahoo.com>
>
>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. 
>
>
>View Pooling is all about "efficient memory management". The state saving algorithm is
another different thing, and the view pool does not affect the way how state saving restoring
works. I unfortunately have to say that your comment does not have sense. This feature is
something new, ouside JSF 2.2 spec but proposed to be included in MyFaces 2.2. What we are
doing here and we have done for more than 1 year is discuss and justify the addition of this
feature.
>
>
>regards,
>
>Leonardo Uribe
>
>
>
>
>
>>
>>Regards,
>>Dora Rajappan.
>>
>>
>>
>>On Friday, December 13, 2013 2:21 PM, Thomas Andraschko <andraschko.thomas@gmail.com>
wrote:
>>  
>>Cool leo! Thanks for your effort :)
>>
>>
>>
>>
>>
>>2013/12/13 Leonardo Uribe <lu4242@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 <lu4242@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.thomas@gmail.com>
>>>>
>>>>Hi Leo,
>>>>>
>>>>>sounds fine! thanks :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>2013/12/9 Leonardo Uribe <lu4242@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
>>>>>> 
>>>>> 
>>>> 
>>> 
>>
>>
>>    
>
> 
>
>    
Mime
View raw message