I think we allowed too many ways for the user to do the same thing again. if we put in this restriction, this command would fail and user has to use PARTITION_PROXY type to create an accessor region, which is not a bad thing after all.
So now, the rule is: 1. when user creates a non-proxy region (no matter on what group, what type), a region with the same name can not exist already in the cluster 2. When user creates a proxy region, a region with the same name has to exist on the cluster first. would this be a reasonable rule to enforce when creating regions using gfsh? On Feb 2, 2018 12:02 PM, "Sai Boorlagadda" <sai.boorlaga...@gmail.com> wrote: > I dont think allowing *_PROXY types with same names is sufficient. Users > can also create accessor regions by setting 'local-max-memory' for a > partition region (though not allowed for a replicate). > > gfsh>create region --name=test --type=PARTITION --local-max-memory=0 > Member | Status > --------------- | ------------------------------------------ > yell-gifted-cow | Region "/test" created on "server1" > > Here /test becomes an accessor region just like when created using the > shortcut "PARTITION_PROXY". > > On Fri, Feb 2, 2018 at 11:46 AM, Jinmei Liao <jil...@pivotal.io> wrote: > >> Accessor region is probably a special case. Then can we add this caviar >> then: "user can not create a region with the same name of a different type >> except it's a proxy region"? >> >> On Fri, Feb 2, 2018 at 11:17 AM, Sai Boorlagadda < >> sai.boorlaga...@gmail.com> wrote: >> >>> Agree with Dan. This is the only way I know that you can create accessor >>> regions on peer members. >>> >>> On Fri, Feb 2, 2018 at 11:07 AM, Dan Smith <dsm...@pivotal.io> wrote: >>> >>>> Won't this break any use case were two members need to create the same >>>> region with different attributes? For example someone might have some >>>> members that are empty accessors of a replicated region: >>>> >>>> //Host data on members in group1 >>>> gfsh> create region --name=A --type=REPLICATE --group=group1 >>>> >>>> //Group2 just needs access to data in region A >>>> gfsh> create region --name=A --type=REPLICATE_PROXY --group=group2 >>>> >>>> -Dan >>>> >>>> On Fri, Feb 2, 2018 at 10:19 AM, Jinmei Liao <jil...@pivotal.io> wrote: >>>> >>>>> Currently creating region with the same name on different groups are >>>>> allowed by gfsh. Checks are done further on the servers when creating the >>>>> region to see if the region attributes clashes with any existing region, >>>>> and the operation will fail if types are different. Here is an example >>>>> about this current behavior: >>>>> >>>>> gfsh> create region --name=A --type=REPLICATE --group=group1 // >>>>> success >>>>> >>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 // >>>>> success >>>>> >>>>> gfsh> create region --name=A --type=PARTITION --group=group2 >>>>> --skip-if-exists // skipping >>>>> >>>>> Member | Status >>>>> >>>>> ------- | ----------------------------------------------- >>>>> >>>>> server2 | Skipping "server2". Region "/A" already exists. >>>>> >>>>> >>>>> gfsh>create region --name=A --type=PARTITION --group=group3 >>>>> --skip-if-exists // failure >>>>> >>>>> Member | Status >>>>> >>>>> ------- | ------------------------------------------------------------ >>>>> ------------------------------------------------------------ >>>>> --------------------------------------- >>>>> >>>>> server3 | ERROR: Cannot create PartitionedRegion /A because another >>>>> cache (10.118.33.243(server2:43156)<v4>:1026) has the same region >>>>> defined as a non PartitionedRegion. >>>>> >>>>> We would like to propose catching the name clash earlier in gfsh for >>>>> the last command as well. Since regions are referred to by names in the >>>>> entire cluster (no server grouping considered at all), when trying to >>>>> create a region, we should check for name clash in the entire cluster, not >>>>> just in the specified server group. If we make this change, the behavior >>>>> would be like this: >>>>> >>>>> gfsh> create region --name=A --type=REPLICATE --group=group1 // >>>>> success >>>>> >>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 // Error >>>>> >>>>> ERROR: Region "/A" already exists. >>>>> >>>>> >>>>> gfsh> create region --name=A --type=REPLICATE --group=group2 >>>>> --skip-if-exists // skipping >>>>> >>>>> Skipping: Region "/A" already exists. >>>>> >>>>> gfsh> create region --name=A --type=PARTITION --group=group2 >>>>> --skip-if-exists >>>>> >>>>> Skipping. Region "/A" already exists. >>>>> >>>>> gfsh> create region --name=A --type=PARTITION --group=group3 >>>>> --skip-if-exists >>>>> Skipping. Region "/A" already exists. >>>>> >>>>> >>>>> Basically, the name clash check is on the entire cluster, not just on >>>>> one specific server. This would lead to some change in script behavior, >>>>> but >>>>> keep the command simple and consistent. >>>>> >>>>> Any feedback is welcome. >>>>> >>>>> Cheers >>>>> >>>>> Jinmei >>>>> >>>> >>>> >>> >> >> >> -- >> Cheers >> >> Jinmei >> > >
