"Brekke, Jeff" wrote:
> Thanks for explaining it some more for me. I sort of came into the
> discussion late an just wanted to drop my 2 cents about turbine having some
> work done on its caching system. Just like you state, we could use the
> turbine caching when we need the features of an in memory cache. I was just
> clarifing that we would not be stuck with just one memory cache singleton
> per turbine instance and thoughts to allow multiple caches has been tossed
> about for expanding the turbine caching framework.
> I wasn't attempting to say that the global cache would replace any disk or
> external resource cache. Just that we could use them in implementing our
> services.
>
Never mind if I was harsh. The reason why I think that we should rename
JetspeedDiskCache is because of this kind of confusions. It is very easy to forget
the distinctions. Also, I think there are more features in it that caching. It acts
also as a serializer to external access.
The new service we are planning will enable plugging in a more complex content
management system instead of it.
BTW: The feature of having multiple caches with different policies is already
available?
>
> l8r,
>
> jb
>
> [SNIPPED]
> >
> > 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]
> >
>
> -----------------------------------------------------------------------
>
> 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]
