portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luta, Raphael (VUN)" <Raphael.L...@groupvu.Com>
Subject RE: Bug in JetspeedAccessController re: Profile
Date Tue, 24 Sep 2002 08:06:01 GMT
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>


Mime
View raw message