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 <krosenv...@apache.org> > wrote: > > This is a replicated cache and I see the unexpected behaviour with 2 > nodes. All I'm trying to do is to make sure the newly started server > is not processing requests before its cache is fully populated. It > seems to me you're saying the "get" request will actually be served by > the other node before rebalancing is complete ? > > Kristian > > > 2016-06-13 9:55 GMT+02:00 Denis Magda <dma...@gridgain.com>: >> 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 until data is >> being rebalanced on some node. >> >> — >> Denis >> >>> On Jun 13, 2016, at 10:51 AM, Kristian Rosenvold <krosenv...@apache.org> >>> wrote: >>> >>> 2016-06-13 9:14 GMT+02:00 Denis Magda <dma...@gridgain.com>: >>>> 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, get, etc. until all the data is fully rebalanced on it. However >>>> this doesn’t prevent from getting a cache reference on this node and ask >>>> for current cache size. >>> >>> Unfortunately it does not seem to work that way. I was also >>> considering that it might only apply to put/get operations, so I tried >>> adding a bogus "get" for a non-existing member to see if it would then >>> exhibit any kind of blocking behaviour (and hence make my assert pass >>> 100% of the time). This does not seem to be the case either. Running >>> an explicit rebalance seems to do the trick. This would appear to be a >>> bug unless I misunderstand something. >>> >>> Kristian >>
