We’ve been using DSpace as an outputs repository at ILRI since 2009, and since then we’ve gone through six major versions of DSpace. Starting with version 1.7 we switched our repository to the newer XML-based user interface (XMLUI), which was much easier to customize than the previous JSPUI and allowed us to have different themes for different communities/collections in our repository.

The convenience and flexibility of the XMLUI came at a cost, though. We started seeing seemingly random cache errors with our themes: community A would sometimes show elements from community B’s theme, and no amount of shift-F5, incognito-mode, or client-side tricks would fix it. We soon learned that this could be remedied by clearing the Cocoon cache and restarting Tomcat, but that was pretty inconvenient.

DSpace 1.8 introduced the ability to clear the cache from the web Control Panel, but this was only slightly less inconvenient, as admins aren’t always around when users start seeing strange artifacts in their browsers. 😉

Non-Caching Cocoon Pipelines

As of this writing we have fourteen different XMLUI themes and we are seeing strange theme caching issues more and more often. As I was searching for a solution to this problem I stumbled upon DS-298 on the DSpace bug tracker. In the discussion of that bug there was an interesting tidbit regarding using non-caching pipelines as a potential solution for a flavor of this bug. I gave it a run on our test instance and it worked!

Since then we’ve switched all of our XMLUI themes to non-caching pipelines and caching issues are a thing of the past. I am not sure of the performance implications of this, but our server still has plenty of CPU and RAM to spare, so I’d rather have happy users for now.

Here’s an example of switching ILRI’s community XMLUI theme to use a non-caching pipeline:

diff --git a/dspace/modules/xmlui/src/main/webapp/themes/ILRI/sitemap.xmap b/dspace/modules/xmlui/src/main/webapp/themes/ILRI/sitemap.xmap
index fdf9d08..3c4a36a 100644
--- a/dspace/modules/xmlui/src/main/webapp/themes/ILRI/sitemap.xmap
+++ b/dspace/modules/xmlui/src/main/webapp/themes/ILRI/sitemap.xmap
@@ -34,7 +34,7 @@
         </map:component-configurations>
 
 
-		<map:pipeline>
+		<map:pipeline type="noncaching">
 			<!-- Allow the browser to cache static content for an hour -->
 			<map:parameter name="expires" value="access plus 1 hours"/>
 
@@ -71,7 +71,7 @@
 			these are just stored on disk and passed directly to the
 			browser without any processing.
 		-->
-		<map:pipeline>
+		<map:pipeline type="noncaching">
 			<!-- Never allow the browser to cache dynamic content -->
 			<map:parameter name="expires" value="now"/>
 

We’re currently running DSpace 3.1 and this is working great. I haven’t noticed any extra load or RAM usage, so it seems this is a win win. I suppose the next step is to ease back on the aggressive prohibition of client-side caching (enforced via mod_headers), now that we’ve definitely ruled out browser caches as being the culprit—that ought to make YSlow a bit happier!