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 Tue, 24 Sep 2002 14:23:49 GMT
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>


Mime
View raw message