portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <david.sean.tay...@bbc.co.uk>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Wed, 25 Sep 2002 10:13:23 GMT
Well if its that simple, my vote is +1 for JCS on the implementation of a
PSML cache.

> -----Original Message-----
> From: Weaver, Scott [mailto:Sweaver@rippe.com] 
> Sent: 24 September 2002 15:49
> To: 'Jetspeed Developers List'
> Subject: RE: Bug in JetspeedAccessController re: Profile
> 
> 
> David,
> 
> It's actually pretty simple.  The version I'm using is 
> somewhat dated, but configuring the cache regions are pretty 
> much cut paste from what the example cache.ccf shows with 
> some additional tweaking.  I have never tried the d-cache 
> (never needed it) but it seems only a tad more complex.  
> Adding and retrieving items is as simple as with 
> TurbineGlobalCache.  A plus is that there is no requirement 
> that your objects be added to the cache via a CacheObject 
> wrapper as is the case with the TurbineGlobalCache.
> 
> The documentation on the JCS is straight-forward.  However, 
> it seems that (at least in the past) more advanced features 
> were not apparent.  I think this is because at the time Aaron 
> and James were working pretty steadily on it.   This has 
> probably changed since then as I have not looked at the JCS 
> site in at least a couple of months.
> 
> Last I heard they were working on an event-model (on-expire, 
> on-remove, etc.) for the cache and cached objects themselves, 
> very cool.
> 
> -Scott
> 
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david.sean.taylor@bbc.co.uk]
> > Sent: Tuesday, September 24, 2002 10:24 AM
> > To: 'Jetspeed Developers List'
> > Subject: RE: Bug in JetspeedAccessController re: Profile
> > 
> > Right on Scott.
> > How difficult is it to configure?
> > 
> > > -----Original Message-----
> > > From: Weaver, Scott [mailto:Sweaver@rippe.com]
> > > Sent: 24 September 2002 15:25
> > > To: 'Jetspeed Developers List'
> > > Subject: RE: Bug in JetspeedAccessController re: Profile
> > >
> > >
> > > > > You end up with a cache that has 2 tunable parameters:
> > > > > - maximum number of entries
> > > > > - time to live in the cache
> > > > >
> > > > > I wonder if TurbineCache does not already let you use
> > > this kind of
> > > > > caching policy...
> > >
> > > What about using JCS instead of TurbineGlobalCache?  It is a more 
> > > full-featured caching system. I am currently using it in a 
> > > production turbine-based application.  Both my customer and I are 
> > > VERY pleased with its performance.
> > >
> > > Also the JCS distributed cache could offer (maybe) a partial 
> > > solution to those who are looking to load-balance/high 
> availability 
> > > solution by putting profiles into the distributed cache 
> opposed to 
> > > the session.  That way one, unique copy of the profile could be 
> > > accessed by multiple servers via the JCS d-cache. If the 
> profile did 
> > > not exist in the d-cache, the first server instance requesting it 
> > > would unmarshal the profile and put into the cache. In the case of
> > > a profile change, all Jetspeed server instances would marshal
> > > the PSML profile from the cache, so all server instances
> > > would be synchronized.  You could even go as far as to load
> > > the registries there for the same effect.
> > >
> > > Ooops, I got WAY off the subject. ;)
> > >
> > > Just trying to offer up some food for thought.
> > >
> > > -Scott
> > >
> > > > -----Original Message-----
> > > > From: Glenn Golden [mailto:ggolden@umich.edu]
> > > > Sent: Tuesday, September 24, 2002 8:39 AM
> > > > To: 'Jetspeed Developers List'
> > > > Subject: RE: Bug in JetspeedAccessController re: Profile
> > > >
> > > > An update, after dancing with the code last evening...
> > > >
> > > > The customizers break if I change the place the profile 
> is stored, 
> > > > removing it from the user.temp into the rundata.  I think the 
> > > > customizers expect the profile to have a scope wider than each 
> > > > individual request;
> > > a scope as
> > > > large
> > > > as the many requests of the customization session.  This
> > > scope is fine for
> > > > the customizers, but is wrong for the "user", as they may
> > > be doing other
> > > > things.  I'm spending today fixing the customizers, if I
> > > can figure them
> > > > out
> > > > ;).
> > > >
> > > > The Profile does hold the PSMLDocument, so it's not 
> just a light 
> > > > weight name thing, but the actual document as well.  This
> > > is redundant
> > > > with the caching
> > > > which is in the PSML managers.
> > > >
> > > > The db psml manager has aggressive caching, even caching
> > > misses.  This
> > > > is good as it reduces the backend database access.  There's a 
> > > > refresher thread running to make sure things in the cache
> > > are current
> > > > (well, as current as the refresher which runs by 
> default every 8 
> > > > hours).  Otherwise, the pages just fill up the cache, 
> and memory.
> > > >
> > > > We could add some cache pruning based on LRU to the
> > > refresher thread,
> > > > as Raphael suggests.
> > > >
> > > > I would like to see the Castor PSML manager fixed up 
> for caching 
> > > > to have the same sort of thing as the db one, but I don't
> > > really use it
> > > > much and not at
> > > > all in production.
> > > >
> > > > Back to the customizers.  I believe that they are doing
> > > things to the
> > > > PSML document that is attached to the profile, and if we don't 
> > > > have this live past requests they don't work.  First, I think
> > > this is bad,
> > > > as they are messing with the "live" (and possibly cached) psml 
> > > > document - anyone else visiting the page will see changes
> > > in progress,
> > > > I think, and there's no chance to "cancel" the edit.  
> Also, if the 
> > > > user comes in with another window's request to another 
> profile, it 
> > > > should mess up the customization process.  And if another
> > > user starts
> > > > customizing the same profile, this will also mess things up.
> > > >
> > > > What I want to do is let the customizers have a copy of the
> > > profile /
> > > > psml document to work on.  This copy would be 
> associated with the 
> > > > request profile
> > > > - i.e. the edit copy of the page would be stored in the
> > > state manager
> > > > keyed by the page's profile and user session.  This 
> means that one 
> > > > user could edit any number of pages at a time from different 
> > > > windows, as each custommization
> > > > state would be stored separately. It also means that 
> any other users
> > > > coming
> > > > in would not see the changes until committed, and if the
> > > customizing user
> > > > has another profile open in another window and requests
> > > come in from that,
> > > > nothing is messed up.
> > > >
> > > > When they press the final "Apply" or "Save" or 
> whatever, the copy 
> > > > would be put back into the PSML service, storing it on file
> > > / db and
> > > > in the cache, and the edit copy and other state would 
> be cleared.
> > > >
> > > > I'll look at what that might look like today.
> > > >
> > > > Comments?
> > > >
> > > > - Glenn
> > > >
> > > > > -----Original Message-----
> > > > > From: Luta, Raphael (VUN) [mailto:Raphael.Luta@groupvu.Com]
> > > > > Sent: Tuesday, September 24, 2002 4:06 AM
> > > > > To: 'Jetspeed Developers List'
> > > > > Subject: RE: Bug in JetspeedAccessController re: Profile
> > > > >
> > > > >
> > > > > De : David Sean Taylor [mailto:david.sean.taylor@bbc.co.uk]
> > > > > >
> > > > > > If I remember correctly, when Glenn and I tested the
> > > > > WeakReferences,
> > > > > > they never kept anything in the cache.
> > > > >
> > > > > Huh ? Strange... I'll check into that as soon as I find
> > > 30 minutes.
> > > > >
> > > > > > I agree the current implementation is flawed, but I don't 
> > > > > > think that
> > > > > putting
> > > > > > PSML in the session is the best solution.
> > > > > > It does help with caching, since if the page you request is
> > > > > the same
> > > > > > as
> > > > > the
> > > > > > last request, then it successfully caches the resource.
> > > But if you
> > > > > > go to another page, then back, you will never receive the
> > > > > benefit
> > > > > > of caching.
> > > > >
> > > > > Agreed. My point was mainly to highlight what could be
> > > the possible
> > > > > consequences of changing where is stored the Profile, not 
> > > > > prevent the change.
> > > > >
> > > > > Additionnally, for any Profile caching strategy you may 
> > > > > consider, you need to remember that there's basically 2 main
> > > options for using
> > > > > Jetspeed:
> > > > >
> > > > > - anonymous:
> > > > >   All users access the same sets of PSML over and 
> over without 
> > > > > having the
> > > > >   possibility of customizing their own. In this scenario
> > > not caching
> > > > > documents
> > > > >   have a terrible performance impact (imagine 10 simultaneous 
> > > > > requests to the home
> > > > >   page in a non-caching environment...) so you'll 
> probably want 
> > > > > aggressive caching.
> > > > >
> > > > > - user personalized:
> > > > >   In this scenario most users would use their own PSML
> > > resource and
> > > > > you're pretty
> > > > >   unlikely to get more than 1 request at a time to a
> > > single resource
> > > > > so you don't
> > > > >   want to aggresive caching  since this will complicate the 
> > > > > customization process.
> > > > >
> > > > > The current structure (Session + weakreference) is a 
> compromise 
> > > > > design to balance both requirements. A more correct
> > > approach would
> > > > > be to implement an adaptative caching strategy in the
> > > PSML Manager
> > > > > and allow efficient caching while keeping the Profile
> > > bound to the
> > > > > request.
> > > > >
> > > > > > For this reason, and also for the reason that Im trying
> > > to  make
> > > > > > Jetspeed sessions fully serializable (I know, good luck), I

> > > > > > believe that the PSML Managers will need to have more 
> > > > > > sophisticated caching algorithms for high volume traffic.  
> > > > > > With the Castor
> > > > > implementation,
> > > > > > which is generally low volume, I would suggest dropping the

> > > > > > WeakReferences and using References until a better caching
> > > > > policy is
> > > > > > in place.
> > > > >
> > > > > Hard references will only work if few PSML resources are 
> > > > > accessed (ie few
> > > > > users) and
> > > > > more importantly will lock some memory that never get 
> released.
> > > > >
> > > > > Maybe a better implementation would be to use a last accessed 
> > > > > timestamp and a vulture thread that would remove from 
> cache all 
> > > > > entries that have not been accessed for more than X minutes.
> > > > >
> > > > > You end up with a cache that has 2 tunable parameters:
> > > > > - maximum number of entries
> > > > > - time to live in the cache
> > > > >
> > > > > I wonder if TurbineCache does not already let you use
> > > this kind of
> > > > > caching policy...
> > > > >
> > > > > What do you think ?
> > > > >
> > > > > --
> > > > > Raphaƫl Luta - raphael.luta@groupvu.com
> > > > > Technology and New Initiatives
> > > > > Vivendi Universal Networks - Paris
> > > > >
> > > > > --
> > > > > To unsubscribe, e-mail:
> > > > > <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org> For
> > > > > additional commands,
> > > > > e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
> > > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:   <mailto:jetspeed-dev-
> > > > unsubscribe@jakarta.apache.org>
> > > > For additional commands, e-mail: <mailto:jetspeed-dev- 
> > > > help@jakarta.apache.org>
> > >
> > 
> > 
> > BBCi at http://www.bbc.co.uk/
> > 
> > This e-mail (and any attachments) is confidential and may contain 
> > personal views which are not the views of the BBC unless 
> specifically 
> > stated. If you have received it in error, please delete it 
> from your 
> > system, do not use, copy or disclose the information in any way nor 
> > act in reliance on it and notify the sender immediately. 
> Please note 
> > that the BBC monitors e-mails sent or received. Further 
> communication 
> > will signify your consent to this.
> > 
> > 
> > --
> > To unsubscribe, e-mail:   <mailto:jetspeed-dev-
> > unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:jetspeed-dev- 
> > help@jakarta.apache.org>
> 


BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain 
personal views which are not the views of the BBC unless specifically 
stated.
If you have received it in error, please delete it from your system, do 
not use, copy or disclose the information in any way nor act in 
reliance on it and notify the sender immediately. Please note that the 
BBC monitors e-mails sent or received. Further communication will 
signify your consent to this.


--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message