myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Sat, 23 Nov 2013 22:49:05 GMT
Hi

Some time ago it was discussed under these topics:

   [core][proposal] JSF View Pooling (going beyond JSF Stateless Mode)

   http://markmail.org/message/54rb3aphc6txwzbr

   [core][discuss] Is it worth to include Stateless JSF / View Pooling
concept into MyFaces?

   http://markmail.org/message/pc42cbcvvhlboivb

The advantages and disadvantages of include view pooling into MyFaces.

With the recent work done in:

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

And other tests done, some assumptions over this topic have changed. For
example:

Before:

- The use ui:param uses EL VariableResolver, makes the view non poolable,
because the ValueExpression instances are not stateless in this case.

After:

EL expressions under "alwaysRecompile" mode can be cacheable and it was
verified that no information related to the state is included into EL
expressions, so if two component trees were created by the same
facelet under the same conditions, they will have both the same
EL expressions.

Before:

- It is difficult to keep the code synchronized between versions of JSF,
because each concept related to view handling affects how the view pool
works.

After:

Now is the right time to include it, because we are now in JSF 2.2, and
all new features should go there.

Before:

- It could create memory fragmentation, making garbage collection slower.
- Higher memory footprint.

After:

The view pool holds the views using a soft reference, so the garbage
collector will be able to collect the views at any time. There is no need
to worry about memory fragmentation.

The increase of memory use due to the view pool is not significant compared
with the savings of memory usage in general.

Before:

- Detection technique to enable this optimization is not 100% fail-safe.

After:

It is still true, because some components needs to be compatible with the
technique, but with MYFACES-3825 if all components in a view are compatible
we can be sure that the view is poolable.

The current disadvantage list is this:

- Detection technique to enable this optimization is not 100% fail-safe.
- Third party libraries needs to be compatible with the technique.
- Complexity can be too high, (but we can reduce the burden doing some
proper documentation).

Do the advantages justify the introduction of this concept? In my personal
opinion probably yes by two main reasons:

- It improves significantly the time spent in ajax request.
- If all components in a view are compatible, that view is poolable.

Should we include it in MyFaces 2.2.x? why not? after all, it is something
that can be optional. For example, libraries like Trinidad provides
org.apache.myfaces.trinidad.
CACHE_VIEW_ROOT web config param. This feature
is something that aims to the same and it is even better.

I think it is worth to give another round to this topic and see what
happens.

regards,

Leonardo Uribe

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

___________________________

Don't miss it:

CONFESS_2014@ JavaLand 2014 <http://www.javaland.eu/en/javaland-2014.html>

____________________________

Mime
View raw message