"Brekke, Jeff" wrote:
> [SNIPPED]
> > > Turbine GlobalCacheService exists already we can easily provide
> > > additional implementation if needed.
> > >
> > > However note that we don't want a single cache instance for
> > the whole
> > > application, we may need different cache instance of different
> > > implementations running at the same time for caching different
> > > kind of elements.
> >
> > That's the right way to go. Portals could then be tuned by
> > replacing the default cache implementations for the different kinds
> > of elements by cache implementations that are optimized for particular
> > environments.
> >
> > > The Turbine service API does address this as such
> > > since it's singleton based but it may be possible to extend it.
> > > I don't know yet but it first require a careful analysis
> > > of what needs to be cached and what are the desired caching
> > properties
> > > for each of these elements.
> >
> > This is a good approach. Maybe we can classify the elements by their
> > lifetime, location (remote resource vs. local file system) and
> > their associated entities (user, user-session, portal, portlet, etc.)
> > Are there more parameters ? I'd expect that depending on the usage
> > scenario of the portal, different caching policies will be appropriate
> > for the different element classes. We should create up with a list of
> > different usage scenarios against which we can validate our ideas.
> [SNIPPED]
>
> FYI, I think there was talk on the Turbine list about supporting multiple
> cache singletons with different policies. Can't remember if these changes
> were made yet. I'll try to check it out or someone could check the mail
> lists.
>
I insist that we are mixing discussions here.
Turbine cache is a memory based one, where the user of the service puts an object and
then retrieves it.
We need more than that. Our JetspeedDiskCache retrieves a URL (taking care of
different threads doing the same), copies it to local disk, and it COULD store it in
memory additionally. It handles issues such as Character encoding, avoiding repeated
accesses to external servers, ...
The turbine cache has no support for retrieving urls or similar features.
Our ExternalResourceManager (I have a name for it, I think JetspeedDiskCache is not
good) is a service that:
- fetches (and serializes network access to) external, url-based resources (rss
channels, dtds, user psml, content channels, ...)
- checks for expiration of the network content and refreshes it if needed
- MAYBE stores these objects as a MRU Memory Cache.
When we migrate it, it should be used for all URL based access to objects in the
system. For instance, to recover a channel or a user psml. Maybe even a template.
This way, the administrator will be able to specify at deployment the "location map"
for a server to retrieve external resources.
The service that does currently memory caching in Jetspeed is the MemoryStore, taken
from Cocoon. This object can be substituted by either the Turbine GlobalCacheService
or the Avalon similar component. But, even if you do that, you will still have the
problem of handling the different urls as a singleton (i.e. avoid loading 500 times
the netscape DTD on startup).
Beware that if we cache external URLs in memory, we will have to handle, currently,
above 2000 objects, with a typical size of aroud 4 KB (the feeds are about 2MB each).
The cache size in my copy is 9,1 MBytes of xml files. Most of the objects are rarely
used, just once in a while when getPortlet() causes expiration or the feeder is run.
Also, beware that if different objects use different caches without a clear control
point (ResourceManager module), there is a risk that there are tough programming
errors, or else that we end up repeating code to avoid problems like having separate
threads in a race condition for getting a resource and sending bursts of requests to
our content management servers.
>
> jb
>
> -----------------------------------------------------------------------
>
> This message has been scanned for viruses with Trend Micro's Interscan VirusWall.
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
