jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jackrabbit & clustering
Date Tue, 06 Jun 2006 08:11:33 GMT
Hi Giota,

Giota Karadimitriou wrote:
> Hello,
>  
> 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);
>                             cache.evict(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
> POINTER 
>                     }
>  
> 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 
>  
> is2.copy(is1);
> is2.notifyUpdated();
>  
> ?

Looking at the implementation of the push() method which is basically a 
copy(), this should also work.

The reason for the NullPointerException is the missing listener 
collection in ItemState, which is declared as transient. That means, if 
you de-serialize an ItemState it kind of become invalid because of the 
missing listener collection. I'm not sure if this is a 'bug'. But since 
you are not interested in having listeners on that item anyway, you 
should be fine.

> 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
> problem?

well, the basic problem you already encountered: what happens to 
listeners of an ItemState. Because listeners are not serializable, this 
information gets lost. Which I think is ok, but you just have to be 
aware of it...

> 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.

I think a node should only acquire locks on other nodes that are 
actually part of the running cluster. If a node is not in the game you 
simply don't ask for locks on that node.

regards
  marcel

Mime
View raw message