I do want the second one. Proxy region should be allowed only if it's on a different member (as far as I gather from the discussion). If I am trying to create a proxy region on serve1, but server1 already has a REPLICATE region with the same name, I should abort the creation.
On Tue, Feb 6, 2018 at 8:00 AM, Michael Stolz <[email protected]> wrote: > Seems like you don't want the second one. Proxy should be allowed, yes? > > -- > Mike Stolz > Principal Engineer, GemFire Product Lead > Mobile: +1-631-835-4771 <(631)%20835-4771> > Download the new GemFire book here. > <https://content.pivotal.io/ebooks/scaling-data-services-with-pivotal-gemfire> > > On Tue, Feb 6, 2018 at 10:56 AM, Jinmei Liao <[email protected]> wrote: > >> Based on these feedback, could we do this instead? >> >> 1. creating non-proxy region: check to see if there is a non-proxy region >> with the same name on the entire cluster or not. If yes, abort the creation. >> 2. creating proxy region: check to see if there is any region with the >> same name on the group or not, if yes, abort the creation. >> >> I think this would catch all cases. >> >> >> >> On Sat, Feb 3, 2018 at 12:01 AM, Swapnil Bawaskar <[email protected]> >> wrote: >> >>> 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 >>>>>>> >>>>>> >>>>>> >>>> >> >> >> -- >> Cheers >> >> Jinmei >> > > -- Cheers Jinmei
