Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Kristian Rosenvold
Great stuff ! I looked at your branch and the fix and the testcases look really neat :) This community rocks ! Kristian 2016-06-14 2:57 GMT+02:00 Alexey Goncharuk : > Kristian, > > Got it, thank you for reporting this. Your expectations are correct, there > is an

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Alexey Goncharuk
Kristian, Got it, thank you for reporting this. Your expectations are correct, there is an issue with handling of SYNC rebalance mode for dynamically started cache. If your cache was set in IgniteConfiguration, you would get correct size without calling rebalance().get(); I created an issue [1]

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Kristian Rosenvold
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

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Alexey Goncharuk
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

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Kristian Rosenvold
> Yes, the newly started node won’t be considered for cache related operations > until the rebalancing has finished. The rest of the nodes will be processing > all the cache related operations like there is no new node at all. Sweet ! I'm not really sure if I missed this in the documentation or

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Denis Magda
Yes, the newly started node won’t be considered for cache related operations until the rebalancing has finished. The rest of the nodes will be processing all the cache related operations like there is no new node at all. — Denis > On Jun 13, 2016, at 10:59 AM, Kristian Rosenvold

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Denis Magda
Kristian, How many nodes do you have in the cluster? If there are more than two server nodes then there shouldn’t be any blocking because while rebalancing is happening on one node the other node can accept and fulfill cache related operations. The main point is that the cluster won’t stuck

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Kristian Rosenvold
2016-06-13 9:14 GMT+02:00 Denis Magda : > This property means that a node that is being started and where a part of > cache data is being rebalanced won’t be considered for any cache related > operations until the rebalancing has finished. > > In my understanding such a node

Re: State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-13 Thread Denis Magda
Hi Kristian, This property means that a node that is being started and where a part of cache data is being rebalanced won’t be considered for any cache related operations until the rebalancing has finished. In my understanding such a node won’t be considered for cache operations like put,

State of initially started cache with CacheRebalanceMode.SYNC ?

2016-06-09 Thread Kristian Rosenvold
The javadoc on CacheRebalanceMode.SYNC seems to indicate that the cache should block until rebalancing is complete. When I run the code below, the assert statement fails unless I add the explicit call to cache.rebalance().get(). Am I doing something wrong ? Kristian CacheConfiguration config =