myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Chen" <Danny.C...@chordiant.com>
Subject RE: Proposal to Externalize the ViewCache.
Date Wed, 14 Nov 2007 05:56:29 GMT
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: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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 <Danny.Chen@chordiant.com> 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: mwessendorf@gmail.com [mailto:mwessendorf@gmail.com] 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 <dannyjrobinson@gmail.com> 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 < Danny.Chen@chordiant.com> 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.

Mime
View raw message