Hi Danny, do you mind to create an jira issue on this, that explains a bit the "issue" ? The "pluggable" system sounds good to me and making it optional by introducing a ctx-param sounds fine as well.
once the jira is there, we can "schedule" it. How does that sound ? -Matthias On Nov 8, 2007 6:02 AM, Danny Chen <[EMAIL PROTECTED]> wrote: > Hi Matthias, > > Thanks for the valuable comments. We went ahead and create a skeleton > solution based on the outlined design. Instead of storing the ViewCache > in the session, we keep it the JCS cache. It works great. We cut down > our session memory usage by 90%. We did quite a bit of testing on it. > We have yet to find any issue. > > Yes, we would like to make this as an option only and it will be > configurable via web.xml. We would not change the current default > setting. On top of this configuration, we would also make the cache > configurable. Out of the box, we would provide the integration to JCS > cache. But if others want to use IBM DCache or any other caching > systems, they could provide their own implementation of > TokenExternalCache interface. > > Since there is no objection to this enhancement proposal, what is the > next step I should do? Should create a Jira item for this and provide > the contributed codes? How can I get this into the roadmap? > > Thanks, > Danny Chen > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Matthias Wessendorf > Sent: Tuesday, November 06, 2007 9:08 PM > To: MyFaces Development > Cc: Danny Robinson > Subject: Re: Proposal to Externalize the ViewCache. > > 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 > 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. > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ mail: matzew-at-apache-dot-org
