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
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]
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
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
> 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
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
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
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
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,
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 =
10 matches
Mail list logo