On Apr 24, 2008, at 7:55 PM, Niels Mayer 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?
We'd like to replace it with jboss cache but we haven't found the time
yet... there's a patch in jira that needs to be reviewed and adapted.
If anyone has an itch to scratch please go ahead :)
As Niels said, note that we didn't succeed in clustering xwiki with
terracotta in the little time we had but we voluntarily didn't want to
spend much time too. This blog was just a very nice report on the
session we had with the great Terracotta folks (we had organized a
XWiki meet up and they offered to host us with pizzas, drink, office
space, etc). How nice is that? :)
Right now the working (not tried it myself) solution we offer is with
clustered oscache but I don't know the config.
Thanks
-Vincent
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.