*correction to my last email, I was using java api and not cache.xml On Fri, Apr 27, 2018 at 3:40 PM Jason Huynh <jhu...@pivotal.io> wrote:
> Hi Jinmei and Naba, > > I don't think you can define two regions with the same name and different > types. We would throw an IllegalStateException for the node that tried to > create the region second. At least that was the behavior I was seeing when > I tried to create a replicate region and a partitioned region with the same > name (admittedly using the java api and not cluster config). So then if > you run a gfsh command to create an index, it would only create the index > on the first node and report back to cluster config the first nodes > configuration and the new index. > > Going back to the original proposal, if the user ever wanted to have the > cluster config updated with the region, how would they sync up their > cluster config without bringing everything down? Sure they can export xml > and bring up another server with xml but that doesn't get them migrated to > cluster config... > > > > On Fri, Apr 27, 2018 at 2:48 PM Jinmei Liao <jil...@pivotal.io> wrote: > >> 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 <(631)%20835-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 <(631)%20835-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 >> >
