Hi, Naba, I believe this is possible even before, with or without using cluster configuration. That's why we have to say stuff defined using cache.xml is not mean to be a cluster wide configuration.
On Fri, Apr 27, 2018 at 2:40 PM, Nabarun Nag <n...@apache.org> wrote: > With the new implementation, will it allow two different regions with the > same exact name to exist in the cluster ? > > I meant like server A had a cache.xml with region “test” with different > properties as to the cache.xml in server B for region “test”. And the > locator had an empty cluster config. > > So now when servers A and B start, they will have different regions but the > same name “test”. Because there is no sync up with locator’s cluster > config. > > Pardon me if my understanding is wrong. > > > Regards > Nabarun > > > On Fri, Apr 27, 2018 at 2:23 PM Jinmei Liao <jil...@pivotal.io> wrote: > > > My point is: we can't keep "mending" the wrong behavior, otherwise we can > > not move forward. > > > > On Fri, Apr 27, 2018 at 2:22 PM, Jinmei Liao <jil...@pivotal.io> wrote: > > > > > So the current behavior is, when a customer starts a server with > > cache.xml > > > that has a region defined, and then later on issues a gfsh command > > `create > > > index` on that region, the command output would be something like: > > > >create index ..... > > > Member | Status > > > ---------------------------- > > > server-1 | Index successfully created. > > > > > > Cluster configuration for "cluster" is not updated > > > Region XYZ does not exist in the cluster configuration (or something to > > > this effect). > > > > > > The command result would tell user exactly what happened and what not > > > happened. The point is, a server's own cache.xml is NOT meant to be a > > > "cluster" wide configuration. If customer is in the habit of starting > up > > > server with cache.xml but yet still want to have consistent > region/index > > > defined in the cluster, export a server's config and use that to start > > > another server. > > > > > > > > > > > > On Fri, Apr 27, 2018 at 2:03 PM, Diane Hardman <dhard...@pivotal.io> > > > wrote: > > > > > >> I talked with Barbara and understand the long term effort to deprecate > > >> cache.xml in favor of cluster config and I heartily agree. > > >> I think a good step in that direction is to provide a migration tool > for > > >> users that reads all cache.xml files for current members and store > them > > in > > >> cluster config, throwing exceptions and logging errors when region > > >> definitions conflict (for the same region name) on different servers > in > > >> the > > >> same cluster. > > >> We might then consider removing the cache.xml files and rely on gfsh > and > > >> (in the future, hopefully) Java API's to keep cluster config > up-to-date. > > >> > > >> Thanks! > > >> > > >> On Fri, Apr 27, 2018 at 12:56 PM, Jinmei Liao <jil...@pivotal.io> > > wrote: > > >> > > >> > The decision is to go with the new behavior (I believe :-)). The > > region > > >> > does not exist in the cluster configuration to begin with since it's > > not > > >> > created using gfsh, so we have no way of checking unless we make an > > >> extra > > >> > trip to the region to find out what kind of region it is, but again > > >> > different server might have different opinion about what it is. > > >> > > > >> > On Fri, Apr 27, 2018 at 12:49 PM, Diane Hardman < > dhard...@pivotal.io> > > >> > wrote: > > >> > > > >> > > Since we are working on enhancing Lucene support to allow adding a > > >> Lucene > > >> > > index to an existing region containing data, I am very interested > in > > >> the > > >> > > decision here. > > >> > > Like Mike, I also prefer keeping the original behavior of updating > > >> > cluster > > >> > > config with both the region and the index if it was not there > > before. > > >> > > Is there something preventing you from checking cluster config > for a > > >> > region > > >> > > of the same name but different properties and, if so, throwing an > > >> > exception > > >> > > (or warning) > > >> > > that cluster config could not be updated due to this collision? > > >> > > > > >> > > On Thu, Apr 19, 2018 at 3:35 PM, Michael Stolz <mst...@pivotal.io > > > > >> > wrote: > > >> > > > > >> > > > 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 > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> > -- > > >> > Cheers > > >> > > > >> > Jinmei > > >> > > > >> > > > > > > > > > > > > -- > > > Cheers > > > > > > Jinmei > > > > > > > > > > > -- > > Cheers > > > > Jinmei > > > -- Cheers Jinmei
