Re: cluster and cache question

[Serge Huber]

While I'm not a huge expert in clustering either, but I do have a little 
bit of experience with it.

Basically, all caches must be able to communicate with other nodes in 
order to guarantee a coherent system. That means that the 
SharedItemStateManager must use a cache that can communicate with other 
nodes of the cluster, otherwise you'll run into problems.

For example : on node 1 you remove a node that is cached on node 2. 
Unless the cache on node 2 is notified, you will be in an incoherent 
state. I know this is basic clustering, so sorry if I'm stating the 
obvious here :)

So the basic rule of thumb is : everywhere there is a cache/hashmap that 
is used to keep objects a memory, there should be a way to substitute 
this for a clustered-aware cache implementation.

Also, I have used OSCache for clustering implementations, and although 
it is very good, I also think that it would be a shame to limit 
Jackrabbit to just this implementation. For example, we might want to 
let the door open for clustering commercial cache implementations such 
as Tangosol (not affiliated, it's just an example :)). JCS (at Apache), 
also has some support for clustering, and there are others out there.

In case other cluster communication systems are needed, it might be 
interesting to evaluate JGroups 
(http://www.jgroups.org/javagroupsnew/docs/index.html) or JMS. JGroups 
is already integrated with Tomcat, JBoss and others.

Regards,
 Serge Huber.
ps : I'd be willing to help on this of course, as it is something I am 
also very interested in.

Simon Gash wrote:
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: jackrabbit-dev@incubator.apache.org
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.