1 2 3 Previous Next 35 Replies Latest reply on Jul 31, 2006 5:38 AM by galder.zamarreno Go to original post
      • 30. Re: Reactivating SharedStoreCacheLoader
        brian.stansberry

        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

          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

            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

              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

                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

                  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.

                  1 2 3 Previous Next