myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject [core] Improvements on ResourceHandler (related to MYFACES-3586)
Date Sun, 29 Jul 2012 17:08:14 GMT

A patch has been provided to improve ResourceHandler performance in situations
when the required resource is inside a jar file. See:

This patch opens an old discussion about what should be done by ResourceHandler
and what should be let to other external tools.

In few words, the patch "suppose" that all resources handled by ResourceHandler
are static, and it wants to put a cache, to prevent all necessary calculation
involved in extract the resource from the jar file (or war file when the
application is not extracted) and in that way improve application scalability,
because it exchanges "CPU consumption" with "Memory", which is ok in this case
because files are relatively small and open a jar file over and over to
calculate the same stuff becomes expensive.

In cases like this, usually it is possible to setup the server to deal with
this. For example, Tomcat has some configuration params
(cacheMaxSize/cachingAllowed) to configure this part. Also, it provides
other config params to set up gzip compression

Long time ago, we discussed about create a module in MyFaces Commons, to
create a custom ResourceHandler implementation. Some experiments where done
to provide for example gzip compression, as well with other useful features.
But in that discussion, it was mentioned that things like gzip compression
should not be done there, because this is already done in other places, so
in practice we are duplicating work in this part, so we just removed that
code and let that discussion for later.

But going back to the original problem, there are good reasons to do static
caching or gzip compression inside ResourceHandler:

- ResourceHandler knows which resources are static and which ones are not,
so the necessary logic can be put there, and what is more important, can be
customized and be aligned with JSF spec.
- Since the cache is inside the server, it uses the memory used by the JVM.
With an external module like with an Apache 2.x server, the reserved memory
for caching is not shared with the JVM, so memory tuning becomes a little
bit complex.
- With a good design, it is possible to save some buffers in this part, or
do things like create temporal files and prevent the jar opening or compress
the same file with gzip algorithm over and over.
- Suffix mapping ( use .jsf as extension for resources ) does not play well
with external tools, which usually expect files ending with .js, .css, .png
and other extensions.

In the other side, there are disadvantages:

- There exists other solutions that are faster and better, because they are
well known and already tested, so why bother for this?
- More code to maintain.
- MYFACES-3586 needs more work to be included, because not all resources
handled by ResourceHandler are static (for example the image rendered by
a captcha component needs to be generated dynamically).

In conclusion, we need to clarify the community position about if it is worth
to do it or not, before accept or not a modification like MYFACES-3586. For
now, and to be consistent with previous discussions, the patch will not be
included for now.

Suggestions are welcome.


Leonardo Uribe

View raw message