> > 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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > Sent: Tuesday, September 24, 2002 4:06 AM > > To: 'Jetspeed Developers List' > > Subject: RE: Bug in JetspeedAccessController re: Profile > > > > > > De : David Sean Taylor [mailto:[EMAIL PROTECTED]] > > > > > > 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 - [EMAIL PROTECTED] > > Technology and New Initiatives > > Vivendi Universal Networks - Paris > > > > -- > > To unsubscribe, e-mail: > > <mailto:jetspeed-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]>
