Alexey, we were discussing what was happening in the 10-20 seconds while the cache was being replicated, to find out if any inconsistencies could occur in this window. So I started a first node with a known number of elements, say 1 million. The testcase I showed in the first code was then started as a second replicated node, also with SYNC mode. The assertion failed miserably, and neither did a "get" operation block. But I did not check what Denis said, that a "get" of an element existing in the other node would simply be satisfied by the remote; I only did a get for a non-existant element. And the size grew in the 10-20 seonds after starting the cache until it reached 1 million.
>So either a cache was created by this call and it's size is equal to zero, or >it was created prior to this call >and cache size must be the same on all >nodes in SYNC mode. This is the latter case, but it does not appear to behave the way you describe. So the second node is basically *started* when the first node is up and running with its 1 million cache nodes. The only way I could ensure the consistency (I think) you're describing was by doing an explicit call to cache.rebalance().get() on the new node. Kristian 2016-06-13 20:03 GMT+02:00 Alexey Goncharuk <[email protected]>: > Kristian, > > I am a little bit confused by the example you provided in your first e-mail. > From the code I see that you create a cache dynamically by calling > getOrCreateCache, and the next line asserts that cache size is equal to a > knownRemoteCacheSize. This does not make sense to me because cache creation > is a distributed operation and it is created on all nodes at once. So either > a cache was created by this call and it's size is equal to zero, or it was > created prior to this call and cache size must be the same on all nodes in > SYNC mode. > > More specifically, SYNC rebalance mode means that Ignition.start() and all > public Cache API calls will be blocked until after rebalancing for such a > cache is finished. > > --AG
