What exactly would your cache provide over the existing cache mechanisms suggested in http://jira.xwiki.org/jira/browse/XWIKI-2022 amd http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances combined with an apache httpd front-end and a load-balanced tomcat setup on multiple hosts? Specifically http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances suggests: Mod Expire Configuration vwwwpro-1:~# cat /etc/apache2/conf.d/expires <Location /xwiki/skins/> ExpiresActive on ExpiresDefault "access plus 1 day" </Location> <Location /xwiki/bin/skin/> ExpiresActive on ExpiresDefault "access plus 1 day" </Location> Cache sizes Tune the document cache in xwiki.cfg. The value depends on how much memory you have. The higher the better. A good reasonable value is 1000. xwiki.store.cache.capacity=1000 Rendering cache Some pages are complex to render (they may aggregate outside data for example or do complex and slow queries). For these pages you can add the following to their content to cache them after they are rendered. For example to cache the rendered content for 60 seconds you would add: $context.setCacheDuration(60) -- Niels. http://nielsmayer.com On Thu, Apr 24, 2008 at 7:49 AM, Glenn Everitt &lt;Glenn.Everitt(a)compuware.com&gt; wrote:

Seems like there's more issues raised than solutions in the reference Shiva provided http://orionl.blogspot.com/2007/10/clustering-xwiki.html Seems like delving into this too deeply could leave you forked as "they are planning to replace OSCache with something else" ... Comments? Clustering OSCache Now that XWikiDocument objects were shareable, we worked on adding locking to the com.opensymphony.oscache.general.GeneralCacheAdministrator. I added a named lock to all of the methods which got rid of the lock exceptions, but we ran into a deadlock. I didn't really look at the OSCache code very much, so it's entirely possible that we can get tweak on the OSCache config a little to get it to work, but, considering that they use their own hash-based structures internally, I kind of doubt we'll be able to get OSCache to work right without a bit more real effort building a formal Terracotta integration module. Considering that they are planning to replace OSCache with something else, we decided to stop this avenue. I suggested that we replace the OSCache implementation of the XWiki cache with a quick-and-dirty, simple Map based implementation, but, as Vincent pointed out, that would only show Terracotta working. It wouldn't be something they'd want to integrate into their codebase, since it wouldn't have eviction policies or any of the other nice stuff you expect from a cache implementation. We decided, instead, to pause and revisit the clustered cache component when they get to reimplementing their cache in about a month. Next Steps The next steps as I see them are: - Get clustered caching configured when XWiki replaces OSCache with their next implementation. - Get Lucene clustering working. This will probably require making the Directory instance pluggable, so we can use a RAMDirectory when we want it clustered. - Refining the Terracotta configuration to include only what is needed. We used a *..* include; for startup performance, we might want to identify the set of classes that will actually need to be shared and switch to including those. - Tuning - Automated tests. We discussed the possibility of using the test infrastructure that we're building for the Terracotta forge projects. They also have some XWiki clusters that we can test on. Continued success, of course, will require building automated tests and running them in a continuous integration process.