You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geode.apache.org by Jinmei Liao <ji...@pivotal.io> on 2018/02/02 18:19:32 UTC
[PROPOSAL]: Create region with the same name on different groups in
gfsh should fail early
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
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Jinmei Liao <ji...@pivotal.io>.
Yes, these rules are only at the gfsh level.
On Tue, Feb 6, 2018 at 8:07 AM, Michael Stolz <ms...@pivotal.io> 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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <
>>>>> sbawaskar@pivotal.io> 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 <
>>>>>> sai.boorlagadda@gmail.com> 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 <ji...@pivotal.io>
>>>>>>> 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" <
>>>>>>>> sai.boorlagadda@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 <ji...@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.boorlagadda@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 <ds...@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 <jiliao@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cheers
>>>>>
>>>>> Jinmei
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>>
>
--
Cheers
Jinmei
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Michael Stolz <ms...@pivotal.io>.
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
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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <sbawaskar@pivotal.io
>>>> > 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 <
>>>>> sai.boorlagadda@gmail.com> 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 <ji...@pivotal.io>
>>>>>> 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" <
>>>>>>> sai.boorlagadda@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Cheers
>>>>
>>>> Jinmei
>>>>
>>>
>>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Michael Stolz <ms...@pivotal.io>.
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
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 <ji...@pivotal.io> 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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <sb...@pivotal.io>
>>> 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 <
>>>> sai.boorlagadda@gmail.com> 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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>>
>>> --
>>> Cheers
>>>
>>> Jinmei
>>>
>>
>>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <ms...@pivotal.io> 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 <ji...@pivotal.io> 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 <sb...@pivotal.io>
>> 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 <
>>> sai.boorlagadda@gmail.com> 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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>>
>> --
>> Cheers
>>
>> Jinmei
>>
>
>
--
Cheers
Jinmei
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Michael Stolz <ms...@pivotal.io>.
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
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 <ji...@pivotal.io> 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 <sb...@pivotal.io>
> 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 <sa...@gmail.com>
>> 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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>>>
>>>>>
>>>>>
>>>
>
>
> --
> Cheers
>
> Jinmei
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <sb...@pivotal.io>
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 <sa...@gmail.com>
> 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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>>
>>>>
>>>>
>>
--
Cheers
Jinmei
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
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 <sa...@gmail.com>
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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>>
>>>
>>>
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Sai Boorlagadda <sa...@gmail.com>.
+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 <ji...@pivotal.io> 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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>>
>>
>>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Jinmei Liao <ji...@pivotal.io>.
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" <sa...@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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>>
>
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <ji...@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.boorlagadda@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 <ds...@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 <ji...@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
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Jinmei Liao <ji...@pivotal.io>.
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 <sa...@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 <ds...@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 <ji...@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
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Sai Boorlagadda <sa...@gmail.com>.
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 <ds...@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 <ji...@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
>>
>
>
Re: [PROPOSAL]: Create region with the same name on different groups
in gfsh should fail early
Posted by Dan Smith <ds...@pivotal.io>.
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 <ji...@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
>