Sometimes PROXY regions are used just to pass messages between members. In this use case, there are no regions that store data. Point 2 will break this use case.
On Fri, Feb 2, 2018 at 2:22 PM Sai Boorlagadda <[email protected]> wrote: > +1 to the proposal with the modified rule and favoring region creation > with shortcuts. > > On Fri, Feb 2, 2018 at 1:56 PM, Jinmei Liao <[email protected]> wrote: > >> 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" <[email protected]> >> 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 <[email protected]> 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 < >>>> [email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>> 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 >>>> >>> >>> >
