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:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]] > > 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:[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]> > > > > > 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- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:jetspeed-dev- > [EMAIL PROTECTED]>
