portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Golden <ggol...@umich.edu>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Tue, 24 Sep 2002 12:39:16 GMT
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>


Mime
View raw message