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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
