will do *after* ApacheCon. -m
On Nov 14, 2007 12:56 AM, Danny Chen <[EMAIL PROTECTED]> wrote: > Hi Matthias, > > That sounds great. I just created a jira (TRINIDAD-816) on this. Feel > free to comment on it. > > Thank you for all your help, > Danny Chen > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Matthias Wessendorf > > Sent: Thursday, November 08, 2007 4:43 AM > To: MyFaces Development > Cc: Danny Robinson > Subject: Re: Proposal to Externalize the ViewCache. > > 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 > 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. > 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
