myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)
Date Mon, 17 Dec 2012 16:23:50 GMT
Hi

In the last months, I have been doing some investigations around
"stateless JSF" ideas. The intention is try to find ways to improve
MyFaces Core performance as much as possible, without lose all those
nice features we all are used to.

In summary, the justification around stateless JSF is that, if it is
possible to cut the build view time from a request, there will be an
improvement from both speed and memory perspective. This is true, but
only to some point, because the response time for a request is given
by the build view, validation/invoke application and render response
time.

To get to the same goal, without sacrifice JSF stateful behavior,
other improvements has been already done (cache EL expressions, cache
ids, make tree structure lighter, ...). The idea is cache that
"stateless information" into a place where it can be reused
effectively, which in this case is inside Facelet abstract syntax tree
(AST). This has worked well so far. The side effects of enable these
optimizations has been analysed, and there is a good understanding
about this.

In few words, the basic idea about stateless JSF as proposed
originally by Rudi Simic in his blog is this:

Mark the view as stateless using some attribute.
Use a pool of views, because views are not thread safe.
Before store the view in the pool, use a visitTree call to reset the fields.

Unfortunately, it was quickly found that the implementation proposed
requires a better view pool and try to reset the fields is not
fail-safe, because the component tree also stores more than just the
input field values. Additionally, it doesn't provide a way to use it
for dynamic views.

Provide a thread safe implementation of UIComponent that can be reused
across threads is not a  good solution, because anyway there is some
information that is inside UIComponent and should be stored per
thread, and precisely UIComponent is a place specifically designed to
store that information.

Based on the previous background, the big question is if a solution
based on object pooling pattern can be done effectively for a web
framework like JSF. A good description of the technique and its
trade-off can be found at:

http://en.wikipedia.org/wiki/Object_pool_pattern

In few words, the proposal is go "Beyond JSF Stateless Mode", and
instead blame the state, make it your friend. Let's just take
advantage of the stateful nature of JSF to allow reuse views fully or
partially.

How?

- PSS algorithm can be used to check if a view has been modified or
not, checking its state. So, it can be used to check which components
has state, and if it is possible to provide a way to reset the state
of a component to the initial state set by the first
markInitialState(), restore the state is possible.

- If the view cannot be reset fully, it is possible to use facelets
refreshing algorithm and reuse a view partially.

- Add some additional code to recover a view instance when it is
discarded, and store it into the view pool. This requires some changes
over NavigationHandlerImpl, because it is not possible to reuse a view
and store it in the pool that is still on usage, so it is necessary to
do a "deferred navigation", changing the default ActionListenerImpl
and ensure handleNavigation() is called before end invoke application
phase but outside the visitTree() call.

- In MyFaces there exists the concept of FaceletState. It is possible
to use this concept and cache even dynamic views, because each
different FaceletState can identify an specific view structure.

I have created this issue:

https://issues.apache.org/jira/browse/MYFACES-3664

The intention of this mail is get some feedback from the community
about this topic. I have a working prototype, so the intention is
create a branch for this topic at the end of January and
commit/release this feature for MyFaces Core 2.1.x branch at the end
of March, just for CONFESS 2013 conference (See
https://2013.con-fess.com/ ).

If you have a good idea, doubt, observation or just you want to say
something about this topic, it is a good moment to do it. There is a
lot of details involved that needs to be defined, so the intention is
discuss them and see how they should looks like.

regards,

Leonardo Uribe

Mime
View raw message