Ok. Yes we do have to take the leap :) Let's keep thinking that way. -- 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 6:29 PM, Jinmei Liao <jil...@pivotal.io> wrote: > but this proposed change is one of the effort toward "deprecating > cache.xml". I think we've got to take the leap at one point..... > > On Thu, Apr 19, 2018 at 3:14 PM, Michael Stolz <mst...@pivotal.io> wrote: > > > 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 > > > > > > > > > -- > Cheers > > Jinmei >
