You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Donal Evans <do...@pivotal.io> on 2020/03/30 18:47:03 UTC
[DISCUSS] Redundancy Gfsh Commands
Hey everyone,
An RFC for adding gfsh commands to allow users to restore redundancy to
partitioned regions and to easily check the redundancy status of
partitioned regions has been posted:
https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands.
Please review and comment on this RFC by Monday, 04/06/2020.
Please also note that this RFC has been revised from an earlier draft
version that some of you may have seen, so the content may have changed.
Thanks,
Donal
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Donal Evans <do...@pivotal.io>.
The RFC has been updated in response to the feedback given so far.
Description of the behaviour of the gfsh commands regarding success/failure
cases has been expanded, and the internal API has been updated to reflect
the use of a CompletableFuture instead of the originally proposed
RestoreRedundancyOperation.
Thank you all for your input.
On Wed, Apr 1, 2020 at 10:46 AM Donal Evans <do...@pivotal.io> wrote:
> - If a PR is configured with redundant-copies=0 and I run a restore
>> redundancy operation, will I get an error?
>> - Will I get an error if I run this operation when no partitioned regions
>> exist?
>
>
> A PR configured with zero redundancy will return success status.
>
> There's a subtlety with the second no-op case though, since you could have
> a situation where you call the command with no arguments (include all
> regions) and don't find any partitioned regions, which would be fine, or
> you could have a situation where you explicitly include some regions and
> none of them are found, in which case I'm not sure that returning success
> would be correct. Would it be reasonable to return error in the case that
> all explicitly included region aren't found?
>
> On Wed, Apr 1, 2020 at 9:16 AM Aaron Lindsey <aa...@apache.org>
> wrote:
>
>> > If at least one redundant copy exists for every bucket in the specified
>> regions, the status of the command will be success. If at least one bucket
>> in a region has zero redundant copies, if there is a member in the system
>> with an older version of Geode or if the restore redundancy function
>> encounters an exception, the command will return error status.
>>
>> - If a PR is configured with redundant-copies=0 and I run a restore
>> redundancy operation, will I get an error?
>> - Will I get an error if I run this operation when no partitioned regions
>> exist?
>>
>> I think the proposal should address what should happen in a no-op
>> scenario like the two cases above. I think it should return success in
>> these cases because the operation did not fail, it just didn’t have to do
>> anything to achieve the desired outcome. The reasoning is that this
>> operation will be invoked programmatically to ensure data is redundant
>> before shutting down a member. So it would be run “just in case”, not
>> because we actually know there is data which needs to have redundancy
>> restored.
>>
>> I also +1 Kirk’s idea of using CompletableFuture
>>
>>
>> Aaron
>>
>>
>> > On Mar 31, 2020, at 7:46 AM, Joris Melchior <jm...@pivotal.io>
>> wrote:
>> >
>> > +1
>> >
>> > I like this idea and Kirk's suggestion to use the CompletableFuture as a
>> > standard for asynchronous operations.
>> >
>> > On Mon, Mar 30, 2020 at 2:47 PM Donal Evans <do...@pivotal.io> wrote:
>> >
>> >> Hey everyone,
>> >>
>> >> An RFC for adding gfsh commands to allow users to restore redundancy to
>> >> partitioned regions and to easily check the redundancy status of
>> >> partitioned regions has been posted:
>> >>
>> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
>> >> .
>> >>
>> >> Please review and comment on this RFC by Monday, 04/06/2020.
>> >>
>> >> Please also note that this RFC has been revised from an earlier draft
>> >> version that some of you may have seen, so the content may have
>> changed.
>> >>
>> >> Thanks,
>> >> Donal
>> >>
>> >
>> >
>> > --
>> > *Joris Melchior *
>> > CF Engineering
>> > Pivotal Toronto
>> > 416 877 5427
>> >
>> > “Programs must be written for people to read, and only incidentally for
>> > machines to execute.” – *Hal Abelson*
>> > <https://en.wikipedia.org/wiki/Hal_Abelson>
>>
>>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Donal Evans <do...@pivotal.io>.
Since the deadline for feedback has been reached and there have been no
objections to the proposed changes, this RFC has been moved to "In
Development" status.
Be on the lookout for a PR containing the internal Java API later today!
On Thu, Apr 2, 2020 at 10:16 AM Aaron Lindsey <aa...@apache.org>
wrote:
> Yes, thanks for clarifying.
>
> > On Apr 2, 2020, at 10:12 AM, Donal Evans <do...@pivotal.io> wrote:
> >
> > Re-sending this from the correct email address. I think the original got
> > eaten.
> >
> >
> >> From the RFC:
> >>> The command will return error status if:
> >> I assume this means ERROR or FAILURE (non-success) status. It seems a
> >> little confusing that there are both ERROR and FAILURE statuses. Maybe
> you
> >> could add another section, “the command will return failure status if:”
> to
> >> make it clear when it will be returning an error vs a failure. I think
> this
> >> will be important for users who are triggering the redundancy restore
> >> operation programmatically to understand the difference.
> >
> >
> > This is a little confusing, unfortunately. The issue arises from the fact
> > that in addition to the Status of the RestoreRedundancyResults, which can
> > be SUCCESS, FAILURE or ERROR and describes the status of a restore
> > redundancy operation on one member, a gfsh command can only return either
> > SUCCESS or ERROR result statuses when it is called, which represent the
> > status of the command across all members. The result status of the
> command
> > and the Status of the RestoreRedundancyResults are separate things,
> > although the command's result status will be partially determined from
> the
> > Status values of the RestoreRedundancyResults objects returned by
> function
> > execution on each member.
> >
> > The differentiation between FAILURE and ERROR status for
> > RestoreRedundancyResults is relevant, since there should be different
> > behaviour for "we were unable to create a redundant copy for all buckets
> in
> > a region," which may be due to not enough members hosting that region or
> > some other relatively benign problem, and "we encountered an exception
> > while attempting to restore redundancy and were unable to complete the
> > operation," which could be indicative of a more serious issue.
> >
> > I hope this clarifies things somewhat.
> >
> > On Thu, Apr 2, 2020 at 8:44 AM Aaron Lindsey <aa...@apache.org>
> > wrote:
> >
> >>> Would it be reasonable to return error in the case that
> >>> all explicitly included region aren't found?
> >>
> >> Yes, this sounds reasonable. Thanks for pointing out that subtlety and
> for
> >> updating the RFC.
> >>
> >> From the RFC:
> >>> The command will return error status if:
> >>
> >> I assume this means ERROR or FAILURE (non-success) status. It seems a
> >> little confusing that there are both ERROR and FAILURE statuses. Maybe
> you
> >> could add another section, “the command will return failure status if:”
> to
> >> make it clear when it will be returning an error vs a failure. I think
> this
> >> will be important for users who are triggering the redundancy restore
> >> operation programmatically to understand the difference.
> >>
> >>> On Apr 2, 2020, at 5:18 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >>>
> >>>
> >>>
> >>>> On Apr 1, 2020, at 10:46 AM, Donal Evans <do...@pivotal.io> wrote:
> >>>>
> >>>> There's a subtlety with the second no-op case though, since you could
> >> have
> >>>> a situation where you call the command with no arguments (include all
> >>>> regions) and don't find any partitioned regions, which would be fine
> >>>
> >>> I think in this case it is not an error since all would mean all that
> >> this may apply to.
> >>>
> >>>> or you could have a situation where you explicitly include some
> regions
> >> and
> >>>> none of them are found, in which case I'm not sure that returning
> >> success
> >>>> would be correct. Would it be reasonable to return error in the case
> >> that
> >>>> all explicitly included region aren't found?
> >>>
> >>> I believe this should be the behavior. If any one explicitly listed
> >> region does not exist an error should result.
> >>>
> >>> -Jake
> >>>
> >>
> >>
>
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Aaron Lindsey <aa...@apache.org>.
Yes, thanks for clarifying.
> On Apr 2, 2020, at 10:12 AM, Donal Evans <do...@pivotal.io> wrote:
>
> Re-sending this from the correct email address. I think the original got
> eaten.
>
>
>> From the RFC:
>>> The command will return error status if:
>> I assume this means ERROR or FAILURE (non-success) status. It seems a
>> little confusing that there are both ERROR and FAILURE statuses. Maybe you
>> could add another section, “the command will return failure status if:” to
>> make it clear when it will be returning an error vs a failure. I think this
>> will be important for users who are triggering the redundancy restore
>> operation programmatically to understand the difference.
>
>
> This is a little confusing, unfortunately. The issue arises from the fact
> that in addition to the Status of the RestoreRedundancyResults, which can
> be SUCCESS, FAILURE or ERROR and describes the status of a restore
> redundancy operation on one member, a gfsh command can only return either
> SUCCESS or ERROR result statuses when it is called, which represent the
> status of the command across all members. The result status of the command
> and the Status of the RestoreRedundancyResults are separate things,
> although the command's result status will be partially determined from the
> Status values of the RestoreRedundancyResults objects returned by function
> execution on each member.
>
> The differentiation between FAILURE and ERROR status for
> RestoreRedundancyResults is relevant, since there should be different
> behaviour for "we were unable to create a redundant copy for all buckets in
> a region," which may be due to not enough members hosting that region or
> some other relatively benign problem, and "we encountered an exception
> while attempting to restore redundancy and were unable to complete the
> operation," which could be indicative of a more serious issue.
>
> I hope this clarifies things somewhat.
>
> On Thu, Apr 2, 2020 at 8:44 AM Aaron Lindsey <aa...@apache.org>
> wrote:
>
>>> Would it be reasonable to return error in the case that
>>> all explicitly included region aren't found?
>>
>> Yes, this sounds reasonable. Thanks for pointing out that subtlety and for
>> updating the RFC.
>>
>> From the RFC:
>>> The command will return error status if:
>>
>> I assume this means ERROR or FAILURE (non-success) status. It seems a
>> little confusing that there are both ERROR and FAILURE statuses. Maybe you
>> could add another section, “the command will return failure status if:” to
>> make it clear when it will be returning an error vs a failure. I think this
>> will be important for users who are triggering the redundancy restore
>> operation programmatically to understand the difference.
>>
>>> On Apr 2, 2020, at 5:18 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>>
>>>
>>>> On Apr 1, 2020, at 10:46 AM, Donal Evans <do...@pivotal.io> wrote:
>>>>
>>>> There's a subtlety with the second no-op case though, since you could
>> have
>>>> a situation where you call the command with no arguments (include all
>>>> regions) and don't find any partitioned regions, which would be fine
>>>
>>> I think in this case it is not an error since all would mean all that
>> this may apply to.
>>>
>>>> or you could have a situation where you explicitly include some regions
>> and
>>>> none of them are found, in which case I'm not sure that returning
>> success
>>>> would be correct. Would it be reasonable to return error in the case
>> that
>>>> all explicitly included region aren't found?
>>>
>>> I believe this should be the behavior. If any one explicitly listed
>> region does not exist an error should result.
>>>
>>> -Jake
>>>
>>
>>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Donal Evans <do...@pivotal.io>.
Re-sending this from the correct email address. I think the original got
eaten.
> From the RFC:
> > The command will return error status if:
> I assume this means ERROR or FAILURE (non-success) status. It seems a
> little confusing that there are both ERROR and FAILURE statuses. Maybe you
> could add another section, “the command will return failure status if:” to
> make it clear when it will be returning an error vs a failure. I think this
> will be important for users who are triggering the redundancy restore
> operation programmatically to understand the difference.
This is a little confusing, unfortunately. The issue arises from the fact
that in addition to the Status of the RestoreRedundancyResults, which can
be SUCCESS, FAILURE or ERROR and describes the status of a restore
redundancy operation on one member, a gfsh command can only return either
SUCCESS or ERROR result statuses when it is called, which represent the
status of the command across all members. The result status of the command
and the Status of the RestoreRedundancyResults are separate things,
although the command's result status will be partially determined from the
Status values of the RestoreRedundancyResults objects returned by function
execution on each member.
The differentiation between FAILURE and ERROR status for
RestoreRedundancyResults is relevant, since there should be different
behaviour for "we were unable to create a redundant copy for all buckets in
a region," which may be due to not enough members hosting that region or
some other relatively benign problem, and "we encountered an exception
while attempting to restore redundancy and were unable to complete the
operation," which could be indicative of a more serious issue.
I hope this clarifies things somewhat.
On Thu, Apr 2, 2020 at 8:44 AM Aaron Lindsey <aa...@apache.org>
wrote:
> > Would it be reasonable to return error in the case that
> > all explicitly included region aren't found?
>
> Yes, this sounds reasonable. Thanks for pointing out that subtlety and for
> updating the RFC.
>
> From the RFC:
> > The command will return error status if:
>
> I assume this means ERROR or FAILURE (non-success) status. It seems a
> little confusing that there are both ERROR and FAILURE statuses. Maybe you
> could add another section, “the command will return failure status if:” to
> make it clear when it will be returning an error vs a failure. I think this
> will be important for users who are triggering the redundancy restore
> operation programmatically to understand the difference.
>
> > On Apr 2, 2020, at 5:18 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> >
> >
> >> On Apr 1, 2020, at 10:46 AM, Donal Evans <do...@pivotal.io> wrote:
> >>
> >> There's a subtlety with the second no-op case though, since you could
> have
> >> a situation where you call the command with no arguments (include all
> >> regions) and don't find any partitioned regions, which would be fine
> >
> > I think in this case it is not an error since all would mean all that
> this may apply to.
> >
> >> or you could have a situation where you explicitly include some regions
> and
> >> none of them are found, in which case I'm not sure that returning
> success
> >> would be correct. Would it be reasonable to return error in the case
> that
> >> all explicitly included region aren't found?
> >
> > I believe this should be the behavior. If any one explicitly listed
> region does not exist an error should result.
> >
> > -Jake
> >
>
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Aaron Lindsey <aa...@apache.org>.
> Would it be reasonable to return error in the case that
> all explicitly included region aren't found?
Yes, this sounds reasonable. Thanks for pointing out that subtlety and for updating the RFC.
From the RFC:
> The command will return error status if:
I assume this means ERROR or FAILURE (non-success) status. It seems a little confusing that there are both ERROR and FAILURE statuses. Maybe you could add another section, “the command will return failure status if:” to make it clear when it will be returning an error vs a failure. I think this will be important for users who are triggering the redundancy restore operation programmatically to understand the difference.
> On Apr 2, 2020, at 5:18 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
>
>
>> On Apr 1, 2020, at 10:46 AM, Donal Evans <do...@pivotal.io> wrote:
>>
>> There's a subtlety with the second no-op case though, since you could have
>> a situation where you call the command with no arguments (include all
>> regions) and don't find any partitioned regions, which would be fine
>
> I think in this case it is not an error since all would mean all that this may apply to.
>
>> or you could have a situation where you explicitly include some regions and
>> none of them are found, in which case I'm not sure that returning success
>> would be correct. Would it be reasonable to return error in the case that
>> all explicitly included region aren't found?
>
> I believe this should be the behavior. If any one explicitly listed region does not exist an error should result.
>
> -Jake
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Jacob Barrett <jb...@pivotal.io>.
> On Apr 1, 2020, at 10:46 AM, Donal Evans <do...@pivotal.io> wrote:
>
> There's a subtlety with the second no-op case though, since you could have
> a situation where you call the command with no arguments (include all
> regions) and don't find any partitioned regions, which would be fine
I think in this case it is not an error since all would mean all that this may apply to.
> or you could have a situation where you explicitly include some regions and
> none of them are found, in which case I'm not sure that returning success
> would be correct. Would it be reasonable to return error in the case that
> all explicitly included region aren't found?
I believe this should be the behavior. If any one explicitly listed region does not exist an error should result.
-Jake
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Donal Evans <do...@pivotal.io>.
>
> - If a PR is configured with redundant-copies=0 and I run a restore
> redundancy operation, will I get an error?
> - Will I get an error if I run this operation when no partitioned regions
> exist?
A PR configured with zero redundancy will return success status.
There's a subtlety with the second no-op case though, since you could have
a situation where you call the command with no arguments (include all
regions) and don't find any partitioned regions, which would be fine, or
you could have a situation where you explicitly include some regions and
none of them are found, in which case I'm not sure that returning success
would be correct. Would it be reasonable to return error in the case that
all explicitly included region aren't found?
On Wed, Apr 1, 2020 at 9:16 AM Aaron Lindsey <aa...@apache.org>
wrote:
> > If at least one redundant copy exists for every bucket in the specified
> regions, the status of the command will be success. If at least one bucket
> in a region has zero redundant copies, if there is a member in the system
> with an older version of Geode or if the restore redundancy function
> encounters an exception, the command will return error status.
>
> - If a PR is configured with redundant-copies=0 and I run a restore
> redundancy operation, will I get an error?
> - Will I get an error if I run this operation when no partitioned regions
> exist?
>
> I think the proposal should address what should happen in a no-op scenario
> like the two cases above. I think it should return success in these cases
> because the operation did not fail, it just didn’t have to do anything to
> achieve the desired outcome. The reasoning is that this operation will be
> invoked programmatically to ensure data is redundant before shutting down a
> member. So it would be run “just in case”, not because we actually know
> there is data which needs to have redundancy restored.
>
> I also +1 Kirk’s idea of using CompletableFuture
>
>
> Aaron
>
>
> > On Mar 31, 2020, at 7:46 AM, Joris Melchior <jm...@pivotal.io>
> wrote:
> >
> > +1
> >
> > I like this idea and Kirk's suggestion to use the CompletableFuture as a
> > standard for asynchronous operations.
> >
> > On Mon, Mar 30, 2020 at 2:47 PM Donal Evans <do...@pivotal.io> wrote:
> >
> >> Hey everyone,
> >>
> >> An RFC for adding gfsh commands to allow users to restore redundancy to
> >> partitioned regions and to easily check the redundancy status of
> >> partitioned regions has been posted:
> >>
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
> >> .
> >>
> >> Please review and comment on this RFC by Monday, 04/06/2020.
> >>
> >> Please also note that this RFC has been revised from an earlier draft
> >> version that some of you may have seen, so the content may have changed.
> >>
> >> Thanks,
> >> Donal
> >>
> >
> >
> > --
> > *Joris Melchior *
> > CF Engineering
> > Pivotal Toronto
> > 416 877 5427
> >
> > “Programs must be written for people to read, and only incidentally for
> > machines to execute.” – *Hal Abelson*
> > <https://en.wikipedia.org/wiki/Hal_Abelson>
>
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Aaron Lindsey <aa...@apache.org>.
> If at least one redundant copy exists for every bucket in the specified regions, the status of the command will be success. If at least one bucket in a region has zero redundant copies, if there is a member in the system with an older version of Geode or if the restore redundancy function encounters an exception, the command will return error status.
- If a PR is configured with redundant-copies=0 and I run a restore redundancy operation, will I get an error?
- Will I get an error if I run this operation when no partitioned regions exist?
I think the proposal should address what should happen in a no-op scenario like the two cases above. I think it should return success in these cases because the operation did not fail, it just didn’t have to do anything to achieve the desired outcome. The reasoning is that this operation will be invoked programmatically to ensure data is redundant before shutting down a member. So it would be run “just in case”, not because we actually know there is data which needs to have redundancy restored.
I also +1 Kirk’s idea of using CompletableFuture
Aaron
> On Mar 31, 2020, at 7:46 AM, Joris Melchior <jm...@pivotal.io> wrote:
>
> +1
>
> I like this idea and Kirk's suggestion to use the CompletableFuture as a
> standard for asynchronous operations.
>
> On Mon, Mar 30, 2020 at 2:47 PM Donal Evans <do...@pivotal.io> wrote:
>
>> Hey everyone,
>>
>> An RFC for adding gfsh commands to allow users to restore redundancy to
>> partitioned regions and to easily check the redundancy status of
>> partitioned regions has been posted:
>> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
>> .
>>
>> Please review and comment on this RFC by Monday, 04/06/2020.
>>
>> Please also note that this RFC has been revised from an earlier draft
>> version that some of you may have seen, so the content may have changed.
>>
>> Thanks,
>> Donal
>>
>
>
> --
> *Joris Melchior *
> CF Engineering
> Pivotal Toronto
> 416 877 5427
>
> “Programs must be written for people to read, and only incidentally for
> machines to execute.” – *Hal Abelson*
> <https://en.wikipedia.org/wiki/Hal_Abelson>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Joris Melchior <jm...@pivotal.io>.
+1
I like this idea and Kirk's suggestion to use the CompletableFuture as a
standard for asynchronous operations.
On Mon, Mar 30, 2020 at 2:47 PM Donal Evans <do...@pivotal.io> wrote:
> Hey everyone,
>
> An RFC for adding gfsh commands to allow users to restore redundancy to
> partitioned regions and to easily check the redundancy status of
> partitioned regions has been posted:
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
> .
>
> Please review and comment on this RFC by Monday, 04/06/2020.
>
> Please also note that this RFC has been revised from an earlier draft
> version that some of you may have seen, so the content may have changed.
>
> Thanks,
> Donal
>
--
*Joris Melchior *
CF Engineering
Pivotal Toronto
416 877 5427
“Programs must be written for people to read, and only incidentally for
machines to execute.” – *Hal Abelson*
<https://en.wikipedia.org/wiki/Hal_Abelson>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Dan Smith <ds...@pivotal.io>.
Looks good. I put a few comments inline (look for the yellow highlights).
-Dan
On Mon, Mar 30, 2020 at 2:21 PM Kirk Lund <kl...@apache.org> wrote:
> [I added this as a comment on the wiki page]
>
> You might want to consider making RestoreRedundancyOperation actually
> extend CompletableFuture. The interface is already very similar to Future,
> and if you extend CompletableFuture, then the user of the API can easily
> combine it with other CompletableFutures. It also helps push us in a
> direction of standardizing on Future/CompletableFuture for APIs that
> involve asynchronous computation.
>
> On Mon, Mar 30, 2020 at 11:47 AM Donal Evans <do...@pivotal.io> wrote:
>
> > Hey everyone,
> >
> > An RFC for adding gfsh commands to allow users to restore redundancy to
> > partitioned regions and to easily check the redundancy status of
> > partitioned regions has been posted:
> >
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
> > .
> >
> > Please review and comment on this RFC by Monday, 04/06/2020.
> >
> > Please also note that this RFC has been revised from an earlier draft
> > version that some of you may have seen, so the content may have changed.
> >
> > Thanks,
> > Donal
> >
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Donal Evans <do...@pivotal.io>.
>
> So the "restore redundancy" command is blocking and only returns when the
> operation is finished?
That's correct. The intention is to ensure that redundancy is recovered
before other commands can be issued.
On Mon, Mar 30, 2020 at 6:33 PM Jinmei Liao <ji...@vmware.com.invalid>
wrote:
> So the "restore redundancy" command is blocking and only returns when the
> operation is finished?
>
> On 3/30/20, 2:21 PM, "Kirk Lund" <kl...@apache.org> wrote:
>
> [I added this as a comment on the wiki page]
>
> You might want to consider making RestoreRedundancyOperation actually
> extend CompletableFuture. The interface is already very similar to
> Future,
> and if you extend CompletableFuture, then the user of the API can
> easily
> combine it with other CompletableFutures. It also helps push us in a
> direction of standardizing on Future/CompletableFuture for APIs that
> involve asynchronous computation.
>
> On Mon, Mar 30, 2020 at 11:47 AM Donal Evans <do...@pivotal.io>
> wrote:
>
> > Hey everyone,
> >
> > An RFC for adding gfsh commands to allow users to restore redundancy
> to
> > partitioned regions and to easily check the redundancy status of
> > partitioned regions has been posted:
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands&data=02%7C01%7Cjiliao%40vmware.com%7C788c44ed12d84851d7a708d7d4f042d7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212000696424012&sdata=MrrGhRXEyu5PONoK4ID1HTNpBdLYCkkiYOzcwcY%2BUjs%3D&reserved=0
> > .
> >
> > Please review and comment on this RFC by Monday, 04/06/2020.
> >
> > Please also note that this RFC has been revised from an earlier draft
> > version that some of you may have seen, so the content may have
> changed.
> >
> > Thanks,
> > Donal
> >
>
>
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Jinmei Liao <ji...@vmware.com.INVALID>.
So the "restore redundancy" command is blocking and only returns when the operation is finished?
On 3/30/20, 2:21 PM, "Kirk Lund" <kl...@apache.org> wrote:
[I added this as a comment on the wiki page]
You might want to consider making RestoreRedundancyOperation actually
extend CompletableFuture. The interface is already very similar to Future,
and if you extend CompletableFuture, then the user of the API can easily
combine it with other CompletableFutures. It also helps push us in a
direction of standardizing on Future/CompletableFuture for APIs that
involve asynchronous computation.
On Mon, Mar 30, 2020 at 11:47 AM Donal Evans <do...@pivotal.io> wrote:
> Hey everyone,
>
> An RFC for adding gfsh commands to allow users to restore redundancy to
> partitioned regions and to easily check the redundancy status of
> partitioned regions has been posted:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FGEODE%2FRedundancy%2BGfsh%2BCommands&data=02%7C01%7Cjiliao%40vmware.com%7C788c44ed12d84851d7a708d7d4f042d7%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637212000696424012&sdata=MrrGhRXEyu5PONoK4ID1HTNpBdLYCkkiYOzcwcY%2BUjs%3D&reserved=0
> .
>
> Please review and comment on this RFC by Monday, 04/06/2020.
>
> Please also note that this RFC has been revised from an earlier draft
> version that some of you may have seen, so the content may have changed.
>
> Thanks,
> Donal
>
Re: [DISCUSS] Redundancy Gfsh Commands
Posted by Kirk Lund <kl...@apache.org>.
[I added this as a comment on the wiki page]
You might want to consider making RestoreRedundancyOperation actually
extend CompletableFuture. The interface is already very similar to Future,
and if you extend CompletableFuture, then the user of the API can easily
combine it with other CompletableFutures. It also helps push us in a
direction of standardizing on Future/CompletableFuture for APIs that
involve asynchronous computation.
On Mon, Mar 30, 2020 at 11:47 AM Donal Evans <do...@pivotal.io> wrote:
> Hey everyone,
>
> An RFC for adding gfsh commands to allow users to restore redundancy to
> partitioned regions and to easily check the redundancy status of
> partitioned regions has been posted:
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands
> .
>
> Please review and comment on this RFC by Monday, 04/06/2020.
>
> Please also note that this RFC has been revised from an earlier draft
> version that some of you may have seen, so the content may have changed.
>
> Thanks,
> Donal
>