Hmmm...I think I liked the old behavior better. It was a kind of bridge to cluster config.
I still think we need to be putting much more effort into deprecating cache.xml and much less effort into fixing the (possibly) hundreds of bugs related to using both cache.xml and cluster configuration at the same time. If we can make cluster config complete enough, and deprecate cache.xml, people will stop using cache.xml. -- Mike Stolz Principal Engineer, GemFire Product Lead Mobile: +1-631-835-4771 Download the GemFire book here. <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire> On Thu, Apr 19, 2018 at 5:58 PM, Jinmei Liao <jil...@pivotal.io> wrote: > Scenario: > a locator with cluster configuration enabled and a server started with a > cache.xml that has /regionA defined and connected to this locator. So the > initial state is the locator has an empty cluster configuration for the > cluster, but the server has a region defined in it's cache. > > Old behavior: > when user execute "create index --region=/regionA ...." command using gfsh, > the index creation is successful on the server, and the server returns a > xml section that contains both <region> and <index> elements, CC is updated > with this xml, so the end result is: both region and index end up in the > cluster configuration. > > Problem with old behavior: > Not sure if the region is a cluster wide configuration. What if a region > with the same name, but different type exists on different servers? the xml > returned by different server might be different. > > New behavior: > when user execute "create index --region=/regionA ...." command using gfsh, > the index creation is successful on the server. We failed to find the > region in the existing cluster configuration, so cluster configuration will > NOT be updated. > > I would also suggest that this would not apply to index alone, any element > inside region would have the same behavior change if we approve this. > > Thanks! > > -- > Cheers > > Jinmei >
