-
30. Re: Reactivating SharedStoreCacheLoader
brian.stansberry Jul 20, 2006 5:33 PM (in response to galder.zamarreno)This isn't really a state transfer, right? -- i.e. has nothing to do w/ the state transfer code that I'm currently refactoring :). It's a separate process?
-
31. Re: Reactivating SharedStoreCacheLoader
galder.zamarreno Jul 20, 2006 6:18 PM (in response to galder.zamarreno)No, i was refering to state transfer because it's what i'm doing navigating the in-memory tree and dumping it to the cache loader. I'm not modifying the state transfer code at all
-
32. Re: Reactivating SharedStoreCacheLoader
brian.stansberry Jul 20, 2006 6:22 PM (in response to galder.zamarreno)That's what I figured, but with pieces of state transfer code laying all over my garage floor waiting for me to put them back together, I wanted to make sure :-)
-
33. Re: Reactivating SharedStoreCacheLoader
galder.zamarreno Jul 26, 2006 3:22 PM (in response to galder.zamarreno)I have almost finished implementing this but I've encountered a minor problem.
Let's say that Cache A assumed the role of the coordinator and started to push the state to the cache loader. In the middle of that, if the cache is stopped, the thread which is pushing the state throws an InterruptedException.
This seems to be the result of channel.close() being called. How could we get around it? Any ideas?
This could happen quite often if the new coordinator had a different location configured for the cache loader compared to the previous coordinator and therefore, a state push would require the entire memory state to be pushed down. -
34. Re: Reactivating SharedStoreCacheLoader
manik Jul 30, 2006 11:01 PM (in response to galder.zamarreno)Is this even necessary? If the cache is stopped then it automatically no longer becomes the coord. In which case it's persistent state is irrelevant, even if it is in an indeterminate state.
-
35. Re: Reactivating SharedStoreCacheLoader
galder.zamarreno Jul 31, 2006 5:38 AM (in response to galder.zamarreno)That's fine if there's still some other nodes in the cluster.
Let's say we've got a cluster of A,B and A has just picked the coordinator role and it's pushing the state. If A is stopped in the middle of that, it does not matter that the persistent state is not complete because B will assume coordinator next and would push the in-memory state to the cache loader. Problem solved.
However, if the same happens now happens with B which is the last node, then the persistent state will remain corrupt.
The other potential issue comes from a cluster restart and the coordinator node retrieving the state from a cache loader to which the transfer was not completed successfully.
I'm just trying to think of potential problems.