[PATCH] Re: implementing Cacheable
Hi Joerg,
Attached is a patch against cvs 2.0.5. It implements a caching directory
generator the same way cocoon 2.1 does. An additional sitemap parameter
refreshDelay is used to check the timestamps of the files
periodically. If i should upload this into the patch queue on bugzilla
let me know.
Hope This Helps (tm)
:)
Jorg
Joerg Heinicke wrote:
Hello Jorg,
the caching for the DirectoryGenerator was implemented on 13th of May
in Cocoon 2.1:
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/DirectoryGenerator.java
Is it correct that you did it for Cocoon 2.0? Can you compare your
caching with the one implemented in 2.1? And maybe provide a patch?
Thanks,
Joerg
Jorg Heymans wrote:
OK I understand the caching now a lot better. Anyone wanting to
understand
how to implement his own caching should read
http://wiki.cocoondev.org/Wiki.jsp?page=WritingForCacheEfficiency
http://cocoon.apache.org/2.0/userdocs/concepts/caching.html
Note that in order for your serializer caching to work, the generator
has to
implement cacheable as well because cocoon attempts to cache as far
into the
pipeline as it can! If the start of the pipeline is already not
cacheable
then the rest won't be either! This was the problem for me all along it
seems.
The often used file generator is cacheable, the directorygenerator I was
using is *not*. So I extended the existing DirectoryGenerator with a
CachingDirectoryGenerator implementing Cacheable. I implemented the
interface methods, reconfigured sitemap and voila my content is
delivered
fully cached now in 100ms instead of 3s!!
Thanks again for your help Vladim, I hope this thread has helped other
people as well in understanding cocoon's caching mechanism.
Greetings
Jorg
Index: org/apache/cocoon/generation/DirectoryGenerator.java
===
RCS file:
/home/cvspublic/cocoon-2.0/src/java/org/apache/cocoon/generation/DirectoryGenerator.java,v
retrieving revision 1.3
diff -u -r1.3 DirectoryGenerator.java
--- org/apache/cocoon/generation/DirectoryGenerator.java31 May 2003 01:22:05
- 1.3
+++ org/apache/cocoon/generation/DirectoryGenerator.java14 Jun 2003 22:31:18
-
@@ -51,6 +51,8 @@
package org.apache.cocoon.generation;
import org.apache.avalon.framework.parameters.Parameters;
+import org.apache.cocoon.caching.CacheValidity;
+import org.apache.cocoon.caching.Cacheable;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.ResourceNotFoundException;
import org.apache.cocoon.environment.Source;
@@ -64,10 +66,13 @@
import java.io.IOException;
import java.net.URL;
import java.text.SimpleDateFormat;
+import java.util.ArrayList;
import java.util.Date;
+import java.util.List;
import java.util.Map;
import java.util.Stack;
+
/**
* Generates an XML directory listing.
* p
@@ -105,7 +110,8 @@
* (SMB GmbH) for Virbus AG
* @version CVS $Id: DirectoryGenerator.java,v 1.3 2003/05/31 01:22:05 joerg Exp $
*/
-public class DirectoryGenerator extends ComposerGenerator {
+public class DirectoryGenerator extends ComposerGenerator
+ implements Cacheable {
private static final String FILE = file:;
/** The URI of the namespace of this generator. */
@@ -122,7 +128,7 @@
protected static final String FILENAME_ATTR_NAME= name;
protected static final String LASTMOD_ATTR_NAME = lastModified;
protected static final String DATE_ATTR_NAME= date;
- protected static final String SIZE_ATTR_NAME= size;
+protected static final String SIZE_ATTR_NAME= size;
/*
* Variables set per-request
@@ -139,6 +145,10 @@
protected boolean isRequestedDirectory;
+/** The delay between checks to the filesystem */
+protected long refreshDelay;
+
+protected DirValidity dirvalidity;
/**
* Set the request parameters. Must be called before the generate
@@ -169,6 +179,8 @@
String rePattern = par.getParameter(root, null);
try {
+this.refreshDelay = par.getParameterAsLong(refreshDelay, 1L) * 1000L;
+
getLogger().debug(root pattern: + rePattern);
this.rootRE = (rePattern == null)?null:new RE(rePattern);
@@ -320,6 +332,7 @@
protected void startNode(String nodeName, File path)
throws SAXException {
setNodeAttributes(path);
+dirvalidity.addFile(path);
super.contentHandler.startElement(URI, nodeName, PREFIX+':'+nodeName,
attributes);
}
@@ -347,9 +360,9 @@
attributes.addAttribute(, DATE_ATTR_NAME,
DATE_ATTR_NAME, CDATA,
dateFormatter.format(new Date(lastModified)));
- attributes.addAttribute(, SIZE_ATTR_NAME,
- SIZE_ATTR_NAME, CDATA,
- Long.toString(path.length()));
+attributes.addAttribute(, SIZE_ATTR_NAME
RE: implementing Cacheable [SOLUTION]
OK I understand the caching now a lot better. Anyone wanting to understand
how to implement his own caching should read
http://wiki.cocoondev.org/Wiki.jsp?page=WritingForCacheEfficiency
http://cocoon.apache.org/2.0/userdocs/concepts/caching.html
Note that in order for your serializer caching to work, the generator has to
implement cacheable as well because cocoon attempts to cache as far into the
pipeline as it can! If the start of the pipeline is already not cacheable
then the rest won't be either! This was the problem for me all along it
seems.
The often used file generator is cacheable, the directorygenerator I was
using is *not*. So I extended the existing DirectoryGenerator with a
CachingDirectoryGenerator implementing Cacheable. I implemented the
interface methods, reconfigured sitemap and voila my content is delivered
fully cached now in 100ms instead of 3s!!
Thanks again for your help Vladim, I hope this thread has helped other
people as well in understanding cocoon's caching mechanism.
Greetings
Jorg
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 12. Juni 2003 21:00
To: [EMAIL PROTECTED]
Subject: Re: implementing Cacheable
Jorg Heymans wrote:
Good pointer thanks Vladim :-)
The difference with the xsp page ofcourse is that I cannot access the
requestparameters from within the serializer.
And you should not.
As a matter of fact the
generatekey and cachevalidity gets called before anything else in the
serializer, so I can't generate a key based on the content that is being
processed.
And you should not.
This would be the solution though.
On a different note, if I put in a DeltaTimeCacheValidity(0, 5); and
generate 1 as key this does not affect the performance of my serializer.
It keeps executing at a steady uncached 3 seconds.
Any ideas on how to access request parameters within the serializer,
You don't need request parameters there. The only thing which must
affect cache key generated by serializer is *serializer's state.*
Suppose you have one serializer and it's behavior is different in AM and
PM (it's got two states). Then, you have to generate the key depending
on time of the day:
if (isAM) { return 1 } else { return 2 };
That's it. No request parameters. No content. Only component's state
matters here. Request parameters, session attributes, etc, all taken
care of well before seializer is called.
maybe I
can use a map:param on the serializer in the sitemap maybe?
No. serialize/ tag can't have params.
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing Cacheable [SOLUTION]
Hello Jorg, the caching for the DirectoryGenerator was implemented on 13th of May in Cocoon 2.1: http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/java/org/apache/cocoon/generation/DirectoryGenerator.java Is it correct that you did it for Cocoon 2.0? Can you compare your caching with the one implemented in 2.1? And maybe provide a patch? Thanks, Joerg Jorg Heymans wrote: OK I understand the caching now a lot better. Anyone wanting to understand how to implement his own caching should read http://wiki.cocoondev.org/Wiki.jsp?page=WritingForCacheEfficiency http://cocoon.apache.org/2.0/userdocs/concepts/caching.html Note that in order for your serializer caching to work, the generator has to implement cacheable as well because cocoon attempts to cache as far into the pipeline as it can! If the start of the pipeline is already not cacheable then the rest won't be either! This was the problem for me all along it seems. The often used file generator is cacheable, the directorygenerator I was using is *not*. So I extended the existing DirectoryGenerator with a CachingDirectoryGenerator implementing Cacheable. I implemented the interface methods, reconfigured sitemap and voila my content is delivered fully cached now in 100ms instead of 3s!! Thanks again for your help Vladim, I hope this thread has helped other people as well in understanding cocoon's caching mechanism. Greetings Jorg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
implementing Cacheable
Hi all,
How can I add caching to my custom written serializer? On average my
serializer takes 3 seconds to complete (regardless whether I implement the
cacheable interface or not)
My serializer implements 2 interfaces : Serializer and Cacheable.
Implementation of the caching interface :
public long generateKey() {
//cachekey is long var
//note that the svgserializer returns 1 here
return cacheKey++;
}
/*
* @return
*/
public CacheValidity generateValidity() {
//stole this from the svgserializer
return NOPCacheValidity.CACHE_VALIDITY;
}
Is this implementation correct at all? What do I need to do more? My
serializer is doing some expensive remote calls and gets back binary data,
this is all fairly static though so caching would be in order.
Reading up on the docs, there seems to be an event-cache and stream-cache
available (http://cocoon.apache.org/2.0/userdocs/concepts/caching.html
http://cocoon.apache.org/2.0/userdocs/concepts/caching.html ) , should I
use these ?
Thanks
jorg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing Cacheable
Jorg Heymans wrote:
Hi all,
How can I add caching to my custom written serializer? On average my
serializer takes 3 seconds to complete (regardless whether I implement the
cacheable interface or not)
My serializer implements 2 interfaces : Serializer and Cacheable.
Implementation of the caching interface :
public long generateKey() {
//cachekey is long var
//note that the svgserializer returns 1 here
return cacheKey++;
You should read cacheable.xsp and after reading in also return 1 here.
(Otherwise you will return cahced response only on 2^64 request to the
same resource)
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing Cacheable
Good pointer thanks Vladim :-)
The difference with the xsp page ofcourse is that I cannot access the
requestparameters from within the serializer. As a matter of fact the
generatekey and cachevalidity gets called before anything else in the
serializer, so I can't generate a key based on the content that is being
processed.
This would be the solution though.
On a different note, if I put in a DeltaTimeCacheValidity(0, 5); and
generate 1 as key this does not affect the performance of my serializer.
It keeps executing at a steady uncached 3 seconds.
Any ideas on how to access request parameters within the serializer, maybe I
can use a map:param on the serializer in the sitemap maybe?
Thanks!
=
Jorg Heymans wrote:
Hi all,
How can I add caching to my custom written serializer? On average my
serializer takes 3 seconds to complete (regardless whether I implement the
cacheable interface or not)
My serializer implements 2 interfaces : Serializer and Cacheable.
Implementation of the caching interface :
public long generateKey() {
//cachekey is long var
//note that the svgserializer returns 1 here
return cacheKey++;
You should read cacheable.xsp and after reading in also return 1 here.
(Otherwise you will return cahced response only on 264 request to the same
resource)
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: implementing Cacheable
Jorg Heymans wrote:
Good pointer thanks Vladim :-)
The difference with the xsp page ofcourse is that I cannot access the
requestparameters from within the serializer.
And you should not.
As a matter of fact the
generatekey and cachevalidity gets called before anything else in the
serializer, so I can't generate a key based on the content that is being
processed.
And you should not.
This would be the solution though.
On a different note, if I put in a DeltaTimeCacheValidity(0, 5); and
generate 1 as key this does not affect the performance of my serializer.
It keeps executing at a steady uncached 3 seconds.
Any ideas on how to access request parameters within the serializer,
You don't need request parameters there. The only thing which must
affect cache key generated by serializer is *serializer's state.*
Suppose you have one serializer and it's behavior is different in AM and
PM (it's got two states). Then, you have to generate the key depending
on time of the day:
if (isAM) { return 1 } else { return 2 };
That's it. No request parameters. No content. Only component's state
matters here. Request parameters, session attributes, etc, all taken
care of well before seializer is called.
maybe I
can use a map:param on the serializer in the sitemap maybe?
No. serialize/ tag can't have params.
Vadim
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
