I think that sounds good so far. I'd love to see the an API for that, which allows to "plug" other caches. That said, the default (w/o any config) should be the current behavior.
-M On Nov 14, 2007 2:54 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
