RE: caching for source objects?
-Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 18:40 To: dev@cocoon.apache.org Subject: Re: caching for source objects? * Carsten Ziegeler: Max Pfingsthorn schrieb: I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. CachingSource builds a new Source object every time, that costs a lot for SitemapSource. I'm currently looking for a way to cache the Source objects (that could be configurable with a new request parameter), not only the cached response. The problem is that I don't want to end up with a lots of unreleased sources. The best would be to release sources unused for a certain period of time. Is that possible? Releasing sources is not really a problem. When you get the source from the cache (be it either the serialized one from the Cache or the object itself from the Store), you can ask it for the validity and check it. If it's not valid, release it and make a new one, otherwise use the one you got. There might be a problem with EventCaching this way, since the eventaware code doesn't know about releasing sources (yet). I made an EventAware MRUMemoryStore recently (not sure if I committed it..), so its method to process event caching events can be adjusted to check if the object to be removed is a source and release it first. I'm not sure, but I also think its possible to overload the remove() method of the MRUMemoryStore instead and also catch other evictions. max
Re: caching for source objects?
Max Pfingsthorn schrieb: Hello everyone! I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. Would it be a good idea in general if we subclassed the excalibur source resolver's resolveURI() method to add some caching (and delayed release) of the sources, say, using the o.a.excalibur.store.impl.MRUMemoryStore? I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: caching for source objects?
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 13:07 To: dev@cocoon.apache.org Subject: Re: caching for source objects? Max Pfingsthorn schrieb: Hello everyone! I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. Would it be a good idea in general if we subclassed the excalibur source resolver's resolveURI() method to add some caching (and delayed release) of the sources, say, using the o.a.excalibur.store.impl.MRUMemoryStore? I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. Yes, I saw that one, and it works pretty well. But I thought it would be nicer to have a less intrusive and transparent way of doing the caching... With the CachingSourceFactory, you have to use two protocols, the caching one and the one you actually want to use. So you end up with something like: caching:file://foo.xml Having a way to swap implementations of the SourceResolver and transparently have source caching for every source you use (the ones that produce a non-null cache key, of course) would be nice... Maybe we can take the implementation of the CachingSource/Factory and encapsulate it in a CachingSourceResolver? max
Re: caching for source objects?
Max Pfingsthorn wrote Yes, I saw that one, and it works pretty well. But I thought it would be nicer to have a less intrusive and transparent way of doing the caching... With the CachingSourceFactory, you have to use two protocols, the caching one and the one you actually want to use. So you end up with something like: caching:file://foo.xml Having a way to swap implementations of the SourceResolver and transparently have source caching for every source you use (the ones that produce a non-null cache key, of course) would be nice... Maybe we can take the implementation of the CachingSource/Factory and encapsulate it in a CachingSourceResolver? I think it doesn't make sense to cache *all* sources, for example you don't want to cache file sources, context sources or pipeline sources. So I guess you end up needing some configuration about which sources you want to cache. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: caching for source objects?
* Carsten Ziegeler: Max Pfingsthorn schrieb: I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. CachingSource builds a new Source object every time, that costs a lot for SitemapSource. I'm currently looking for a way to cache the Source objects (that could be configurable with a new request parameter), not only the cached response. The problem is that I don't want to end up with a lots of unreleased sources. The best would be to release sources unused for a certain period of time. Is that possible? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
