> 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 it needs to be added.... Thanks a lot, Kristian 2016-06-13 10:02 GMT+02:00 Denis Magda <[email protected]>: > > — > Denis > >> On Jun 13, 2016, at 10:59 AM, Kristian Rosenvold <[email protected]> >> 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 <[email protected]>: >>> 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 <[email protected]> >>>> wrote: >>>> >>>> 2016-06-13 9:14 GMT+02:00 Denis Magda <[email protected]>: >>>>> 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 >>> >
