]
Brian Stansberry commented on JBCACHE-772:
------------------------------------------
It's not a situation due to a merge. It's a case where the cache's channel
gets suspected and reconnects.
Conceptually very similar to a merge though in that the node's state has become
inconsistent with respect to the cluster, so I could see how a fix would use the same
logic as the JBCACHE-471 solution. I suppose what I wrote in the description is a policy
of "throw away my state and accept the group's state" which is not always
the right answer.
State transfer not handled properly in case of reconnect
--------------------------------------------------------
Key: JBCACHE-772
URL:
http://jira.jboss.com/jira/browse/JBCACHE-772
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Clustering
Affects Versions: 1.4.0.SP1, 1.4.0.GA, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0.GA,
1.2.4SP2, 1.2.4SP1, 1.2.4
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.2.0.GA
In createService(), TreeCache set Channel.AUTO_GET_STATE to true. This should only be
done if the cache is configured to do an initial state transfer.
That's easy to fix. What's harder to fix is what to do when region-based
marshalling is in effect. Probably, something like the following:
1) In viewAccepted, monitor for the case where a view is issue that doesn't include
the current node. Set a flag and ??? (throw exceptions when attempts are made to use the
cache???)
2) When another view is accepted that once again includes the current node, iterate
through the various marshalling regions, inactivating and then reactivating them
(reactivation will cause a partial state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: