[
https://issues.apache.org/jira/browse/TRINIDAD-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542328
]
Danny Chen commented on TRINIDAD-816:
-------------------------------------
To prove this design, we created a skeleton solution based on the outlined
design. We were able to reduce the httpsession memory usage by 90%. In the
coming weeks we will provide a full solution back to the community. The full
solution will be based on an interface. As part of the full solution we will
provide implementation to store view cache in a JCS cache. If others want to
use a different cache, they could implement the outlined interface.
> Externalizing the ViewCache (currently the view cache is stored in the http
> session, this enhancement to to add an option to the framework to move the
> view cache to some other external cache system)
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-816
> URL: https://issues.apache.org/jira/browse/TRINIDAD-816
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Archetype
> Environment: all
> Reporter: Danny Chen
>
> From email:
> **************************
> We like to propose an enhancement to how and where Trinidad maintains its
> view caches. Currently when the system is configured to use token as the
> state persistent method, Trinidad will maintain all component states in a
> ViewCache. This ViewCache is just a map that is maintained in the
> HttpSession. Each page has its own View Cache map. There could be a number
> of ViewCaches stored in a session if multiple frames are being used (which we
> have). During performance testing of our app, we find that this view cache
> consumes a lot of memory. More then 60% of the session memory is occupied
> by the View Cache. With more then 600k in session memory, we can't ensure
> fail over work appropriately and consistently. We tried to use the "all"
> option for client _state_method. But the increase in download time is
> outside of our max threshold.
> After looking through the Trinidad code, we come up with a design to move the
> view caches outside of the session and maintain them in a configurable cache.
> The benefit of this solution is the fact the ViewCache is not in the
> session. Thus, we don't have to replicate them even if we turn on session
> replication. In the case of session fail over, the user would see the pages
> refresh. The user would have to hit submit again to move on to the next.
> Which cache implementation to use, which cache region to use and what the
> expiration is can be configurable through xml. All these logic is controlled
> by a new option (token_external_cache) in CLIENT_STATE_METHOD. These changes
> should be very isolate. We will make most of the changes in
> org.apache.myfaces.trinidadinternal.application.State. This class is where
> the ViewCache is created and used. We would also introduce a new class
> similar to org.apache.myfaces.trinidadinternal.util.TokenCache, call it
> TokenExternalCache. TokenExternalCache will contain all integration logics
> to add/update/read data from the configured cache. If application view cache
> is enabled, none of these logics will get executed.
> We don't' foresee any major difficulty in implementing this solution. And we
> don't foresee any side effort as well. Please let us know what Trinidad
> community think. More importantly please let us know if the Trinidad
> community is welling to accept this solution and get it integrated in a
> future release or not.
> ********
> for more info, refer to 11/2007 developer mailing list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
