Guess there's no reason why the rest of us JackRabbit fans can't chew over a few design ideas around clustering ;)
I was thinking how the 'observer' pattern could be used. Each node of the cluster could have its own JackRabbit repository. The SharedItemState Manager for each node would register with other nodes in the cluster. Whenever an item is changed this is simply broadcast to any other repositories that are listening. There would also need to be a way of dealing with Sessions, unless you implement the 'sticky' session stuff (Session always returning to the same node in the cluster). Anyone else got any ideas... -----Original Message----- From: Stefan Guggisberg [mailto:[EMAIL PROTECTED] Sent: 03 April 2005 12:21 To: [email protected] Subject: Re: cluster and cache question hi edgar, > > regarding clustering: > > clustering is a very interesting topic and we had quite a few > > discussions on how it could be supported in jackrabbit. > is there an archive of this? unfortunately not, those have been only verbal discussions during coffe breaks so far. > > clustering can IMO not be > > entirely delegated to the PM. it has to be tackled on a higher level. > > the sticking point is how to synchronize the multiple jackrabbit > > instances in a cluster. > > > Have you seen the oscache approach for clustering? it seems interesting. i didn't know oscache before, it looks interesting. thanks for the pointer. > I'm just thinking out loud, Local and Shared ItemStateManagers could > favor composition over inheritance. The current ItemStateCache > implementation is a good fit for the first, and an oscache like > approach could be a good choice for the latter in a clustering scenario. > > Maybe this could be a deployment decision, with a "shared-cache" tag > in the config file that leaves to the deployer the cache strategy > selection for shared ItemStates. > > A pluggable cache for shared item states would also be useful for > network deployments with or without clustering. Those who chose a > rdbms backend would be able to to use a cache that relies also in the > local filesystem, and not only in mem. as you might have noticed i am not a huge fan of 'pluggable' core components ;) but i agree with you that tackling clustering on the shared ItemState cache level would be certainly worth thinking about more. but as i said, i think it's a bit too early to address something as complex and advanced as clustering at this stage. > Sorry for being such a pain, I'm becoming a jackrabbit fun and I'd > like to use it on any project I get involved. great to hear that! ...and don't worry about being a pain ;) your feedback and your suggestions, although we might not always be sharing the same position, are very much appreciated. at the very least it forces us to explain and justify design decisions that we've taken. on the other hand it might also lead us to reconsider certain designs. cheers stefan > > thanks > edgar > This email contains proprietary information, some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient you may not use, disclose, distribute, copy, print or rely on this email. Email transmission cannot be guaranteed to be secure or error free, as information may be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. This email and any files attached to it have been checked with virus detection software before transmission. You should nonetheless carry out your own virus check before opening any attachment. GOSS Interactive Ltd accepts no liability for any loss or damage that may be caused by software viruses. GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in the Deloitte Technology Fast 500 EMEA.
