jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Giota Karadimitriou" <Giota.Karadimitr...@eurodyn.com>
Subject RE: jackrabbit & clustering
Date Mon, 05 Jun 2006 18:24:54 GMT
> -----Original Message-----
> From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net]
> Sent: Thursday, May 18, 2006 11:19 PM
> To: dev@jackrabbit.apache.org
> Subject: Re: jackrabbit & clustering
> Giota Karadimitriou wrote:
> > Much obliged for your answer Marcel, things are starting to make
> > thanks to you. Allow me one extra question which again creates
> > for me:
> > is1 is just a copy of a shism1 state, so it does not exist in
shism2; it
> > is just transferred to shism2 (using rmi assumingly)
> >
> > By is1.connect(is2); we make is2 overlaid state of is1 and we add
is1 as
> > listener. then push() copies information from is1 to is2. so far so
> > good. However, isn't it a problem that is1 in reality does not exist
> > shish2?
I have finally put the scenario in action and so far I have encountered
the following problems.
Regarding the actual scenario the problem I came across was in these
much discussed 2 lines of code :
//modifiedIt comes from shism1 
while (modifiedIt.hasNext()){
                ItemState is1=(ItemState)modifiedIt.next();
                ItemId iid=remote.getId();
                log.debug("remotely modifying state:"+iid);
                if (hasItemState(iid)){
                    log.debug("has item state:"+iid);
                    if (hasNonVirtualItemState(iid)){
                        log.debug("has non virtual item state:"+iid);
                        if (cache.isCached(iid)) {
                            log.debug("is cached:"+iid);
                    } else {
                        //virtual or transient
                        log.debug("virtual or transient:"+iid);
                        ItemState is2=getItemState(iid);
                        is1.connect(transState);              //HERE
                        is1.push();                           //HERE
                        is2.notifyStateUpdated();            //NULL
the problem is actually the following:
after connect, is1 becomes the listener for is2 
and push() copies information from is1 to is2 but when is2.notifyUpdated
is invoked I get a null pointer exception because is1 has no listeners.
It is a copy (or even if I pass the actual state and not a copy it is a
serializable state passed from cluster to cluster without listeners
attached to it any more) thus the null pointer.
Maybe I should just do 
I actually transfer the states themselves and not a copy because it is
difficult to make a copy of the state (no suitable constructor or clone
method etc). Besides states are Serializable objects and can be moved
from cluster to cluster using RMI. You think this might create a
Finally regarding locking I implemented some write locking mechanism
following your suggestion to always follow the same order in order to
avoid deadlock situations and it works fine so far. For read locks I
could not do the same because read locks are acquired even on startup
and the problem is the following: first cluster node is e.g. initialized
then distributed read lock tries to be enforced but second cluster is
not yet up and thus it fails with a connection refused exception and RAR
cannot be deployed successfully on both clusters.
Your suggestions have very much helped me in the past (especially the
write locking suggestion to be always in same order) so I would really
appreciate any feedback. Thanks in advance.
> I'm not sure here, but I think it is not a problem, because is1 will
> be short lived. It is just there to transfer the state change to is2
> in
> the end is1 should be destroyed again.
> > It is like an unlinked object state (a copy of an object with no
> > binding/relation to shism2).  Don't we lose the is2 transient state
> > way?
> no, I don't think so. there can be multiple states connected to a
> state. that's in fact what happens when there are multiple sessions
> reading
> from the same item state.
> regards
>   marcel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message