Hi, took a bit..., but I read the proposal from Danny Chen and I think that this sounds interesting. Not sure on the impacts, but the numbers look indeed interesting.
In case that this will end-up in Trinidad, I'd assume, that the default behavior / implementation is what we do now and that the suggested solution becomes an "option" that is configurable. Greetings, Matthias On 11/2/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > There's already an issue raised regarding a configurable cache mechanism > (TRINIDAD-780) to allow the view cache to be externally managed - I'm > assuming that request was also related to your issue. While I've not seen > any feedback from other members on their opinion of such an enhancement, I > can see the benefits, and it could potentially provide a good-enough > failover. > > Members, we'd really welcome any feedback on this topic as the state cached > on the server-side is pretty significant. Additionally, if there are any > other optimizations others can bring to this around clearing out old view > caches - e.g. Could we keep just the most recent one for each > conversation/frame that is open, rather than just caching a given number - > perhaps at the cost of back-button support. Also, are there other options > we could look at around optimzing the state that is cached, as I've seen > comments about Facelets (which is used in this case) already holding much of > the same information, or even ideas such as caching state deltas. > > Regards, > > D. > > > On 10/31/07, Danny Chen < [EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi All, > > > > > > > > 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. > > > > > > > > Thanks, > > > > Chordiant Engineers. > > > > > > The information transmitted herewith is sensitive information of Chordiant > Software or its customers and is intended only for use to the individual or > entity to which it is addressed. If the reader of this message is not the > intended recipient, you are hereby notified that any review, retransmission, > dissemination, distribution, copying or other use of, or taking of any > action in reliance upon, this information is strictly prohibited. If you > have received this communication in error, please contact the sender and > delete the material from your computer. > > > > -- > Chordiant Software Inc. > www.chordiant.com -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
