Yes, these rules are only at the gfsh level. On Tue, Feb 6, 2018 at 8:07 AM, Michael Stolz <[email protected]> wrote:
> If you're only enforcing it at the gfsh or admin api level I guess that > would still be ok. Yep, I think you have the right rules then. > > -- > 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 11:05 AM, Michael Stolz <[email protected]> wrote: > >> Ah, on the same member. That makes sense. What if it is a new member >> joining the group? >> >> -- >> 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 11:03 AM, Jinmei Liao <[email protected]> wrote: >> >>> 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 >>> >> >> > -- Cheers Jinmei
