[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162597#comment-17162597 ] ASF GitHub Bot commented on GEODE-7670: --- jujoramos merged pull request #4848: URL: https://github.com/apache/geode/pull/4848 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8334) Primary and secondary bucket data mismatch with concurrent putAll/removeAll and PR.clear
[ https://issues.apache.org/jira/browse/GEODE-8334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos updated GEODE-8334: -- Fix Version/s: (was: 1.14.0) > Primary and secondary bucket data mismatch with concurrent putAll/removeAll > and PR.clear > - > > Key: GEODE-8334 > URL: https://issues.apache.org/jira/browse/GEODE-8334 > Project: Geode > Issue Type: Sub-task > Components: regions >Affects Versions: 1.14.0 >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7912) cacheWriter should be triggered when PR.clear
[ https://issues.apache.org/jira/browse/GEODE-7912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos updated GEODE-7912: -- Fix Version/s: (was: 1.13.0) > cacheWriter should be triggered when PR.clear > - > > Key: GEODE-7912 > URL: https://issues.apache.org/jira/browse/GEODE-7912 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 3h 10m > Remaining Estimate: 0h > > If server configured cacheWriter, PR.clear should trigger it the same way as > PR.destroyRegion does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7983) Clear region writer callbacks should not be invoked for bucket regions
[ https://issues.apache.org/jira/browse/GEODE-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos updated GEODE-7983: -- Fix Version/s: (was: 1.13.0) > Clear region writer callbacks should not be invoked for bucket regions > -- > > Key: GEODE-7983 > URL: https://issues.apache.org/jira/browse/GEODE-7983 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 50m > Remaining Estimate: 0h > > Region destroy will not trigger cacheWriter for bucket region. we should keep > the same behavior for clear. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162599#comment-17162599 ] ASF subversion and git services commented on GEODE-7670: Commit 1c7f15ff8c0465f402fb1ece530c2ed2f10826b5 in geode's branch refs/heads/feature/GEODE-7665 from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1c7f15f ] GEODE-7670: PR Clear with Concurrent Ops DUnitTests (#4848) Added distributed tests to verify that the clear operation on Partitioned Regions works as expected when there are other concurrent operations happening on the cache (put, putAll, get, remove, removeAll, members added and members removed). > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos resolved GEODE-7670. --- Resolution: Fixed > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7670) Partitioned Region clear operations can occur during concurrent data operations
[ https://issues.apache.org/jira/browse/GEODE-7670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162601#comment-17162601 ] ASF subversion and git services commented on GEODE-7670: Commit 1c7f15ff8c0465f402fb1ece530c2ed2f10826b5 in geode's branch refs/heads/feature/GEODE-7665 from Juan José Ramos [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1c7f15f ] GEODE-7670: PR Clear with Concurrent Ops DUnitTests (#4848) Added distributed tests to verify that the clear operation on Partitioned Regions works as expected when there are other concurrent operations happening on the cache (put, putAll, get, remove, removeAll, members added and members removed). > Partitioned Region clear operations can occur during concurrent data > operations > --- > > Key: GEODE-7670 > URL: https://issues.apache.org/jira/browse/GEODE-7670 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > > Clear operations are successful when concurrent read/write operations occur. > Ensure there are test coverage for this use case and modify the code needed > to enable this. > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with > * concurrent puts (writes) and clear op > * concurrent gets (reads) and clear op > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8374) ViewAckTimeout Configuration
Juan Ramos created GEODE-8374:
-
Summary: ViewAckTimeout Configuration
Key: GEODE-8374
URL: https://issues.apache.org/jira/browse/GEODE-8374
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Juan Ramos
We have the following within our docs (point 4
[here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
{noformat}
In the first phase, the membership coordinator sends out a view preparation
message to all members and waits 12 seconds for a view preparation ack return
message from each member. If the coordinator does not receive an ack message
from a member within 12 seconds, the coordinator attempts to connect to the
member’s failure-detection socket. If the coordinator cannot connect to the
member’s failure-detection socket, the coordinator declares the member dead and
starts the membership view protocol again from the beginning.
{noformat}
These 12 seconds refer to {{viewAckTimeout}} property within the
{{GMSJoinLeave}} class, and it’s calculated as follows:
{code:title=GMSJoinLeave.java|borderStyle=solid}
long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
if (ackCollectionTimeout < 1500) {
ackCollectionTimeout = 1500;
} else if (ackCollectionTimeout > 12437) {
ackCollectionTimeout = 12437;
}
ackCollectionTimeout = Long
.getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
ackCollectionTimeout)
.longValue();
this.viewAckTimeout = ackCollectionTimeout;
{code}
So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}}, unless
the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system property (for
which I haven't found any tests nor anything related, meaning that _*it
shouldn't be used at all as we don't know what the negative implications - if
any - are*_).
We should either remove the internal check and allow the user to fully
configure this property ({{member-timeout * 2}} by default) or add better
documentation about this internal timeout and why it shouldn't be changed
outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-8374:
--
Priority: Minor (was: Major)
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Priority: Minor
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - are*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-8374:
--
Component/s: docs
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Priority: Minor
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a member within 12 seconds, the coordinator attempts to connect to the
> member’s failure-detection socket. If the coordinator cannot connect to the
> member’s failure-detection socket, the coordinator declares the member dead
> and starts the membership view protocol again from the beginning.
> {noformat}
> These 12 seconds refer to {{viewAckTimeout}} property within the
> {{GMSJoinLeave}} class, and it’s calculated as follows:
> {code:title=GMSJoinLeave.java|borderStyle=solid}
> long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
> if (ackCollectionTimeout < 1500) {
> ackCollectionTimeout = 1500;
> } else if (ackCollectionTimeout > 12437) {
> ackCollectionTimeout = 12437;
> }
> ackCollectionTimeout = Long
> .getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
> ackCollectionTimeout)
> .longValue();
> this.viewAckTimeout = ackCollectionTimeout;
> {code}
> So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
> seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}},
> unless the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system
> property (for which I haven't found any tests nor anything related, meaning
> that _*it shouldn't be used at all as we don't know what the negative
> implications - if any - are*_).
> We should either remove the internal check and allow the user to fully
> configure this property ({{member-timeout * 2}} by default) or add better
> documentation about this internal timeout and why it shouldn't be changed
> outside of the fixed interval.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8374) ViewAckTimeout Configuration
[
https://issues.apache.org/jira/browse/GEODE-8374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-8374:
--
Description:
We have the following within our docs (point 4
[here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
{noformat}
In the first phase, the membership coordinator sends out a view preparation
message to all members and waits 12 seconds for a view preparation ack return
message from each member. If the coordinator does not receive an ack message
from a member within 12 seconds, the coordinator attempts to connect to the
member’s failure-detection socket. If the coordinator cannot connect to the
member’s failure-detection socket, the coordinator declares the member dead and
starts the membership view protocol again from the beginning.
{noformat}
These 12 seconds refer to {{viewAckTimeout}} property within the
{{GMSJoinLeave}} class, and it’s calculated as follows:
{code:java|title=GMSJoinLeave.java|borderStyle=solid}
long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
if (ackCollectionTimeout < 1500) {
ackCollectionTimeout = 1500;
} else if (ackCollectionTimeout > 12437) {
ackCollectionTimeout = 12437;
}
ackCollectionTimeout = Long
.getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
ackCollectionTimeout)
.longValue();
this.viewAckTimeout = ackCollectionTimeout;
{code}
So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}}, unless
the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system property (for
which I haven't found any tests nor anything related, meaning that _*it
shouldn't be used at all as we don't know what the negative implications - if
any - might be*_).
We should either remove the internal check and allow the user to fully
configure this property ({{member-timeout * 2}} by default) or add better
documentation about this internal timeout and why it shouldn't be changed
outside of the fixed interval.
was:
We have the following within our docs (point 4
[here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
{noformat}
In the first phase, the membership coordinator sends out a view preparation
message to all members and waits 12 seconds for a view preparation ack return
message from each member. If the coordinator does not receive an ack message
from a member within 12 seconds, the coordinator attempts to connect to the
member’s failure-detection socket. If the coordinator cannot connect to the
member’s failure-detection socket, the coordinator declares the member dead and
starts the membership view protocol again from the beginning.
{noformat}
These 12 seconds refer to {{viewAckTimeout}} property within the
{{GMSJoinLeave}} class, and it’s calculated as follows:
{code:title=GMSJoinLeave.java|borderStyle=solid}
long ackCollectionTimeout = config.getMemberTimeout() * 2 * 12437 / 1;
if (ackCollectionTimeout < 1500) {
ackCollectionTimeout = 1500;
} else if (ackCollectionTimeout > 12437) {
ackCollectionTimeout = 12437;
}
ackCollectionTimeout = Long
.getLong(GeodeGlossary.GEMFIRE_PREFIX + "VIEW_ACK_TIMEOUT",
ackCollectionTimeout)
.longValue();
this.viewAckTimeout = ackCollectionTimeout;
{code}
So, the actual value for the {{viewAckTimeout}} is {{member-timeout * 2}}
seconds, but it can’t be lower than {{1.5}}, neither higher than {{12}}, unless
the user configures the undocumented {{VIEW_ACK_TIMEOUT}} system property (for
which I haven't found any tests nor anything related, meaning that _*it
shouldn't be used at all as we don't know what the negative implications - if
any - are*_).
We should either remove the internal check and allow the user to fully
configure this property ({{member-timeout * 2}} by default) or add better
documentation about this internal timeout and why it shouldn't be changed
outside of the fixed interval.
> ViewAckTimeout Configuration
>
>
> Key: GEODE-8374
> URL: https://issues.apache.org/jira/browse/GEODE-8374
> Project: Geode
> Issue Type: Bug
> Components: docs, membership
>Reporter: Juan Ramos
>Priority: Minor
>
> We have the following within our docs (point 4
> [here|https://geode.apache.org/docs/guide/112/managing/network_partitioning/how_network_partitioning_management_works.html]):
> {noformat}
> In the first phase, the membership coordinator sends out a view preparation
> message to all members and waits 12 seconds for a view preparation ack return
> message from each member. If the coordinator does not receive an ack message
> from a membe
[jira] [Updated] (GEODE-8375) No-op test to run Redis API for Geode for local development
[ https://issues.apache.org/jira/browse/GEODE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8375: --- Priority: Trivial (was: Major) > No-op test to run Redis API for Geode for local development > --- > > Key: GEODE-8375 > URL: https://issues.apache.org/jira/browse/GEODE-8375 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Sarah Abbey >Priority: Trivial > > No-op test to run Redis API for Geode for local development -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8375) No-op test to run Redis API for Geode for local development
Sarah Abbey created GEODE-8375: -- Summary: No-op test to run Redis API for Geode for local development Key: GEODE-8375 URL: https://issues.apache.org/jira/browse/GEODE-8375 Project: Geode Issue Type: Test Components: redis Reporter: Sarah Abbey No-op test to run Redis API for Geode for local development -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7685) Add backward compatibility tests for PartitionedRegion clear
[ https://issues.apache.org/jira/browse/GEODE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-7685: -- Labels: GeodeCommons pull-request-available (was: GeodeCommons) > Add backward compatibility tests for PartitionedRegion clear > > > Key: GEODE-7685 > URL: https://issues.apache.org/jira/browse/GEODE-7685 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, pull-request-available > > Partitioned region clear must gracefully reject the operation request if > there are older version of Apache Geode are present in the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8375) No-op test to run Redis API for Geode for local development
[ https://issues.apache.org/jira/browse/GEODE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8375: -- Labels: pull-request-available (was: ) > No-op test to run Redis API for Geode for local development > --- > > Key: GEODE-8375 > URL: https://issues.apache.org/jira/browse/GEODE-8375 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Sarah Abbey >Priority: Trivial > Labels: pull-request-available > > No-op test to run Redis API for Geode for local development -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8375) No-op test to run Redis API for Geode for local development
[ https://issues.apache.org/jira/browse/GEODE-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162850#comment-17162850 ] ASF GitHub Bot commented on GEODE-8375: --- sabbeyPivotal opened a new pull request #5392: URL: https://github.com/apache/geode/pull/5392 No-op test to run Redis API for Geode for local development This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > No-op test to run Redis API for Geode for local development > --- > > Key: GEODE-8375 > URL: https://issues.apache.org/jira/browse/GEODE-8375 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Sarah Abbey >Priority: Trivial > > No-op test to run Redis API for Geode for local development -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7685) Add backward compatibility tests for PartitionedRegion clear
[ https://issues.apache.org/jira/browse/GEODE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162852#comment-17162852 ] ASF GitHub Bot commented on GEODE-7685: --- jujoramos opened a new pull request #5393: URL: https://github.com/apache/geode/pull/5393 Added distributed tests to make sure PartitionRegion.clear() operation nicely handles scenarios on which there are older members on the system; that is, members that don't have any code to handle the clear operation for this type of region yet. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [X] Is your initial contribution a single, squashed commit? - [X] Does `gradlew build` run cleanly? - [X] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add backward compatibility tests for PartitionedRegion clear > > > Key: GEODE-7685 > URL: https://issues.apache.org/jira/browse/GEODE-7685 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons > > Partitioned region clear must gracefully reject the operation request if > there are older version of Apache Geode are present in the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8376) PartitionRegion.clear should fail when older members host the region to be cleared
Juan Ramos created GEODE-8376:
-
Summary: PartitionRegion.clear should fail when older members host
the region to be cleared
Key: GEODE-8376
URL: https://issues.apache.org/jira/browse/GEODE-8376
Project: Geode
Issue Type: Sub-task
Components: regions
Reporter: Juan Ramos
The {{PartitionClear.clear()}} operation should be smart enough and fail fast
whenever there are old members (that is, members running versions older than
the version on which the {{clear}} operation is released) within the
distributed system hosting the actual region that has to be cleared.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8366) A non-persistent partitioned region attached to a non-persistent gateway sender throws an exception if its leader co-located region is persistent
[
https://issues.apache.org/jira/browse/GEODE-8366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162938#comment-17162938
]
ASF subversion and git services commented on GEODE-8366:
Commit cfc9fe179932040340efb24b14b34bf4c5fa5a40 in geode's branch
refs/heads/feature/GEODE-8366 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cfc9fe1 ]
GEODE-8366: Force CI to re-run
> A non-persistent partitioned region attached to a non-persistent gateway
> sender throws an exception if its leader co-located region is persistent
> -
>
> Key: GEODE-8366
> URL: https://issues.apache.org/jira/browse/GEODE-8366
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> With this configuration:
> {noformat}
> enable-persistence="false" remote-distributed-system-id="1"/>
>
>
>
> redundant-copies="1"/>
>
>
> {noformat}
> An exception is thrown, and the Cache fails to start.
> The error and exception are:
> {noformat}
> [error 2020/07/16 14:06:59.908 PDT tid=0x1]
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> {noformat}
> {noformat}
> Exception in thread "main"
> org.apache.geode.internal.cache.wan.GatewaySenderException: Non persistent
> gateway sender non_persistent_sender can not be attached to persistent region
> /persistent_parent
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:470)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:459)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3115)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2975)
> {noformat}
> The ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR method
> currently compares the data policy of the input region's leader region with
> the sender's persistence policy. It assumes the input region and the leader
> region have the same data policy. In this scenario, that is not the case. The
> input region is 'non_persistent_child' which is not persistent, and the
> leader region is 'persistent_parent' which is persistent. The sender is
> 'non_persistent_sender' which is not persistent. So, instead of comparing the
> data policy of 'non_persistent_child' to the sender which would succeed since
> they are both not persistent, it compares the data policy of
> 'persistent_parent' to the sender which fails since one is persistent, and
> the other is not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8371) ClassGraph license should be attributed to MIT in LICENSE
[ https://issues.apache.org/jira/browse/GEODE-8371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8371. -- Fix Version/s: 1.14.0 Resolution: Fixed > ClassGraph license should be attributed to MIT in LICENSE > - > > Key: GEODE-8371 > URL: https://issues.apache.org/jira/browse/GEODE-8371 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > ClassGraph license should be attributed to MIT instead of BSD in LICENSE. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8316) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
[
https://issues.apache.org/jira/browse/GEODE-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8316:
--
Labels: CI GeodeOperationAPI pull-request-available (was: CI
GeodeOperationAPI)
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
> ---
>
> Key: GEODE-8316
> URL: https://issues.apache.org/jira/browse/GEODE-8316
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
> Labels: CI, GeodeOperationAPI, pull-request-available
>
> {noformat}
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.10.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.11.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.12.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8316) RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
[
https://issues.apache.org/jira/browse/GEODE-8316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162959#comment-17162959
]
ASF GitHub Bot commented on GEODE-8316:
---
jinmeiliao opened a new pull request #5394:
URL: https://github.com/apache/geode/pull/5394
…nce it needs to do installDist first.
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> RollingUpgradeWithGfshDUnitTest > testRollingUpgradeWithDeployment[] FAILED
> ---
>
> Key: GEODE-8316
> URL: https://issues.apache.org/jira/browse/GEODE-8316
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> {noformat}
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.10.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.11.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:08
> 07:26:08org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeWithGfshDUnitTest
> > testRollingUpgradeWithDeployment[1.12.0] FAILED
> 07:26:08java.lang.AssertionError:
> 07:26:08Expecting file:
> 07:26:08
>
> 07:26:08to exist.
> 07:26:19 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
Dave Barnes created GEODE-8377: -- Summary: User Guide: GFSH GC command should be documented to use only in non-production environments Key: GEODE-8377 URL: https://issues.apache.org/jira/browse/GEODE-8377 Project: Geode Issue Type: Improvement Components: docs Reporter: Dave Barnes [DWisler] The GSFH GC command is very likely to cause members of GemFire to be kicked out due to being unresponsive, as this is a forced GC event and not always handled well by GC outside of normal GC processing. We need to document that this should only be used in non-production environments, and to not use it if it causes such issues. We are especially susceptible if multiple members run on the same vm/host and/or if the number of cpus is insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8378) Clean up SNI proxy tests usage of keystore, truststore files
Diane Hardman created GEODE-8378: Summary: Clean up SNI proxy tests usage of keystore, truststore files Key: GEODE-8378 URL: https://issues.apache.org/jira/browse/GEODE-8378 Project: Geode Issue Type: Improvement Components: native client Reporter: Diane Hardman Follow-up to GEODE-7508. New SNI proxy tests still contain local copies of keystore and truststore files which should be removed and these tests updated to reference the common files. This will prevent these tests from becoming brittle over time. Here's where I found the extraneous files: find . -name *.jks ./ssl_keys/server_keys/server_keystore.jks ./ssl_keys/server_keys/server_truststore.jks ./cppcache/integration/test/sni-test-config/geode-config/server-clementine-keystore.jks ./cppcache/integration/test/sni-test-config/geode-config/server-dolores-keystore.jks ./cppcache/integration/test/sni-test-config/geode-config/truststore.jks ./cppcache/integration/test/sni-test-config/geode-config/locator-maeve-keystore.jks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163031#comment-17163031 ] ASF subversion and git services commented on GEODE-8377: Commit 939ec631bfe59ec0c2483e8032f040acaac236bf in geode's branch refs/heads/feature/GEODE-8377 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=939ec63 ] GEODE-8377: User Guide: GFSH GC command should be documented to use only in non-production environments > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Major > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8377: -- Labels: pull-request-available (was: ) > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163032#comment-17163032 ] ASF GitHub Bot commented on GEODE-8377: --- davebarnes97 opened a new pull request #5396: URL: https://github.com/apache/geode/pull/5396 ...to be used only in non-production environments This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Major > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8298) member version comparison sense inconsistent when deciding on multicast
[
https://issues.apache.org/jira/browse/GEODE-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163046#comment-17163046
]
ASF subversion and git services commented on GEODE-8298:
Commit 78e182ee7675b1aa22f20735a5cfbe1a0c9f9e03 in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=78e182e ]
Revert "GEODE-8298: Fix multicast version detection (#5370)"
This reverts commit fd76cc0b
> member version comparison sense inconsistent when deciding on multicast
> ---
>
> Key: GEODE-8298
> URL: https://issues.apache.org/jira/browse/GEODE-8298
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available, starter
> Fix For: 1.14.0
>
>
> Since about 2014 when we introduced the {{Version}} class to replace use of
> {{short}} s all over the place for serialization versions, these two loops in
> {{GMSMembership.processView()}} have used comparisons that disagree in sense:
> {code}
> // We perform the update under a global lock so that other
> // incoming events will not be lost in terms of our global view.
> latestViewWriteLock.lock();
> try {
> // first determine the version for multicast message serialization
> VersionOrdinal version = Version.CURRENT;
> for (final Entry internalIDLongEntry : surpriseMembers
> .entrySet()) {
> ID mbr = internalIDLongEntry.getKey();
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && version.compareTo(itsVersion) < 0) {
> version = itsVersion;
> }
> }
> for (ID mbr : newView.getMembers()) {
> final VersionOrdinal itsVersion = mbr.getVersionObject();
> if (itsVersion != null && itsVersion.compareTo(version) < 0) {
> version = mbr.getVersionObject();
> }
> }
> disableMulticastForRollingUpgrade = !version.equals(Version.CURRENT);
> {code}
> The goal here is to find the oldest version and if that version is older than
> our local version we disable multicast. So we want to put the minimum into
> {{version}}. So the first loop's comparison is wrong and the second one is
> right.
> While we are in here let's combine the two loops using
> {{Stream.concat(surpriseMembers.entrySet().stream().map(entry->entry.getKey()),
> newView.getMembers().stream()).forEach(member -> ...)}}.
> Alternatives are described here:
> https://www.baeldung.com/java-combine-multiple-collections
> Once we have the combined {{Iterable}} we can use something like
> {{Collections.min()}} to find the minimum in one swell foop and this whole
> thing collapses to one or two declarative expressions.
> When this story is complete, the functionality will be in a separate method
> and we'll have a unit test for it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163047#comment-17163047
]
ASF subversion and git services commented on GEODE-8337:
Commit 12f393db502245a88e85da8a6a9286fc7980101a in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=12f393d ]
Revert "GEODE-8337: git mv VersionOrdinal.java->Version.java"
This reverts commit 2a3b609c
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8337) Rename Version enum to KnownVersion; VersionOrdinal to Version
[
https://issues.apache.org/jira/browse/GEODE-8337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163048#comment-17163048
]
ASF subversion and git services commented on GEODE-8337:
Commit 76a034b795ea4c30ec081816b47cd2a00daa29c3 in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=76a034b ]
Revert "GEODE-8337: git mv Version.java->KnownVersion.java"
This reverts commit 17d66791
> Rename Version enum to KnownVersion; VersionOrdinal to Version
> --
>
> Key: GEODE-8337
> URL: https://issues.apache.org/jira/browse/GEODE-8337
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> As a follow-on to GEODE-8240 and GEODE-8330, this is the final ticket, to
> rename:
> {{Version}} -> {{KnownVersion}}
> {{VersionOrdinal}} -> {{Version}}
> With this ticket, the work started in GEODE-8240 is complete.
> After this change, the versioning hierarchy will be:
> !screenshot-1.png!
> Before this change, the hierarchy was:
> !screenshot-2.png!
> As part of this story we'll also harmonize version access methods on
> MemberIdentifier, InternalDistributedMember, and GMSMemberData:
> getVersionOrdinalObject() becomes getVersion()
> On GMSMemberData:
> setVersionObjectForTest() becomes setVersionForTest()
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-8377: -- Assignee: Dave Barnes > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8308) Some formatting text visible in the docs
[ https://issues.apache.org/jira/browse/GEODE-8308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-8308: --- Fix Version/s: 1.14.0 > Some formatting text visible in the docs > > > Key: GEODE-8308 > URL: https://issues.apache.org/jira/browse/GEODE-8308 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.14.0 > > > See > [https://geode.apache.org/docs/guide/112/reference/statistics_list.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163093#comment-17163093 ] ASF GitHub Bot commented on GEODE-8377: --- davebarnes97 merged pull request #5396: URL: https://github.com/apache/geode/pull/5396 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-8377. Fix Version/s: 1.14.0 Resolution: Fixed > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163095#comment-17163095 ] ASF subversion and git services commented on GEODE-8377: Commit 6a0e2bccfc40434087914913a50896424d9f8b92 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6a0e2bc ] GEODE-8377: User Guide: GFSH GC command should be documented ... (#5396) * GEODE-8377: User Guide: GFSH GC command should be documented to use only in non-production environments > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8377) User Guide: GFSH GC command should be documented to use only in non-production environments
[ https://issues.apache.org/jira/browse/GEODE-8377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163094#comment-17163094 ] ASF subversion and git services commented on GEODE-8377: Commit 6a0e2bccfc40434087914913a50896424d9f8b92 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6a0e2bc ] GEODE-8377: User Guide: GFSH GC command should be documented ... (#5396) * GEODE-8377: User Guide: GFSH GC command should be documented to use only in non-production environments > User Guide: GFSH GC command should be documented to use only in > non-production environments > --- > > Key: GEODE-8377 > URL: https://issues.apache.org/jira/browse/GEODE-8377 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > [DWisler] The GSFH GC command is very likely to cause members of GemFire to > be kicked out due to being unresponsive, as this is a forced GC event and not > always handled well by GC outside of normal GC processing. We need to > document that this should only be used in non-production environments, and to > not use it if it causes such issues. We are especially susceptible if > multiple members run on the same vm/host and/or if the number of cpus is > insufficient to handle the “load” needed by GC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
