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
