[jira] [Commented] (GEODE-8765) NullPointerException if group-transaction-events enabled and mix of puts with transactions and without transactions
[ https://issues.apache.org/jira/browse/GEODE-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248862#comment-17248862 ] ASF GitHub Bot commented on GEODE-8765: --- mkevo merged pull request #5829: URL: https://github.com/apache/geode/pull/5829 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 > NullPointerException if group-transaction-events enabled and mix of puts with > transactions and without transactions > --- > > Key: GEODE-8765 > URL: https://issues.apache.org/jira/browse/GEODE-8765 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is enabled and Geode receives a mix of puts, > some inside transactions and some not in transactions, in the case it is > needed to add extra events to the batch in order to have all the events for > each transaction in the given batch, if the sender runs into an event not > belonging to a transaction while looking for events in the queue, a > NullPointerException is thrown when trying to get the transactionId for the > event. The exception is caught by the sender processor and a warning message > is written in the log but some undesired effects are provoked: > > * In parallel gateway senders, this situation provokes that the batch is > sent without completing the transactions and also some events are left in the > queues forever without ever being drained (although all the events are sent > to the other side). > * In serial gateway senders, this situation provokes that once the exception > is thrown, no more events are sent to the other side as the events in the > last batch that could not be sent because the exception was thrown are tried > to be sent over and over without success. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8765) NullPointerException if group-transaction-events enabled and mix of puts with transactions and without transactions
[ https://issues.apache.org/jira/browse/GEODE-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248864#comment-17248864 ] ASF subversion and git services commented on GEODE-8765: Commit 4c00984eb3c32972b4b03fdbe2b6397decdc177f in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c00984 ] GEODE-8765: Fix NullPointerException when group-transaction-events an… (#5829) * GEODE-8765: Fix NullPointerException when group-transaction-events and events in and not in transactions are sent. > NullPointerException if group-transaction-events enabled and mix of puts with > transactions and without transactions > --- > > Key: GEODE-8765 > URL: https://issues.apache.org/jira/browse/GEODE-8765 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is enabled and Geode receives a mix of puts, > some inside transactions and some not in transactions, in the case it is > needed to add extra events to the batch in order to have all the events for > each transaction in the given batch, if the sender runs into an event not > belonging to a transaction while looking for events in the queue, a > NullPointerException is thrown when trying to get the transactionId for the > event. The exception is caught by the sender processor and a warning message > is written in the log but some undesired effects are provoked: > > * In parallel gateway senders, this situation provokes that the batch is > sent without completing the transactions and also some events are left in the > queues forever without ever being drained (although all the events are sent > to the other side). > * In serial gateway senders, this situation provokes that once the exception > is thrown, no more events are sent to the other side as the events in the > last batch that could not be sent because the exception was thrown are tried > to be sent over and over without success. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8765) NullPointerException if group-transaction-events enabled and mix of puts with transactions and without transactions
[ https://issues.apache.org/jira/browse/GEODE-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248863#comment-17248863 ] ASF subversion and git services commented on GEODE-8765: Commit 4c00984eb3c32972b4b03fdbe2b6397decdc177f in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c00984 ] GEODE-8765: Fix NullPointerException when group-transaction-events an… (#5829) * GEODE-8765: Fix NullPointerException when group-transaction-events and events in and not in transactions are sent. > NullPointerException if group-transaction-events enabled and mix of puts with > transactions and without transactions > --- > > Key: GEODE-8765 > URL: https://issues.apache.org/jira/browse/GEODE-8765 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When group-transaction-events is enabled and Geode receives a mix of puts, > some inside transactions and some not in transactions, in the case it is > needed to add extra events to the batch in order to have all the events for > each transaction in the given batch, if the sender runs into an event not > belonging to a transaction while looking for events in the queue, a > NullPointerException is thrown when trying to get the transactionId for the > event. The exception is caught by the sender processor and a warning message > is written in the log but some undesired effects are provoked: > > * In parallel gateway senders, this situation provokes that the batch is > sent without completing the transactions and also some events are left in the > queues forever without ever being drained (although all the events are sent > to the other side). > * In serial gateway senders, this situation provokes that once the exception > is thrown, no more events are sent to the other side as the events in the > last batch that could not be sent because the exception was thrown are tried > to be sent over and over without success. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8765) NullPointerException if group-transaction-events enabled and mix of puts with transactions and without transactions
[ https://issues.apache.org/jira/browse/GEODE-8765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez resolved GEODE-8765. -- Fix Version/s: 1.14.0 Resolution: Fixed > NullPointerException if group-transaction-events enabled and mix of puts with > transactions and without transactions > --- > > Key: GEODE-8765 > URL: https://issues.apache.org/jira/browse/GEODE-8765 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When group-transaction-events is enabled and Geode receives a mix of puts, > some inside transactions and some not in transactions, in the case it is > needed to add extra events to the batch in order to have all the events for > each transaction in the given batch, if the sender runs into an event not > belonging to a transaction while looking for events in the queue, a > NullPointerException is thrown when trying to get the transactionId for the > event. The exception is caught by the sender processor and a warning message > is written in the log but some undesired effects are provoked: > > * In parallel gateway senders, this situation provokes that the batch is > sent without completing the transactions and also some events are left in the > queues forever without ever being drained (although all the events are sent > to the other side). > * In serial gateway senders, this situation provokes that once the exception > is thrown, no more events are sent to the other side as the events in the > last batch that could not be sent because the exception was thrown are tried > to be sent over and over without success. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
Alberto Gomez created GEODE-8783: Summary: Publish batchesWithIncompleteTransactions in GatewaySenderMXBean Key: GEODE-8783 URL: https://issues.apache.org/jira/browse/GEODE-8783 Project: Geode Issue Type: Improvement Components: docs, jmx, wan Reporter: Alberto Gomez It would be interesting to have a counter called "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the number of batches sent with incomplete transactions. The reason is that it may not be guaranteed that all the events for a transaction will be sent in the same batch, even if group-transaction-events is enabled, due to a wrong configuration or under very high traffic conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[ https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-8783: Assignee: Alberto Gomez > Publish batchesWithIncompleteTransactions in GatewaySenderMXBean > > > Key: GEODE-8783 > URL: https://issues.apache.org/jira/browse/GEODE-8783 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > It would be interesting to have a counter called > "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the > number of batches sent with incomplete transactions. > The reason is that it may not be guaranteed that all the events for a > transaction will be sent in the same batch, even if group-transaction-events > is enabled, due to a wrong configuration or under very high traffic > conditions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[ https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-8783: - Description: It would be interesting to have a counter called "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the number of batches sent with incomplete transactions. The reason is that it may not be guaranteed that all the events for a transaction will be sent in the same batch, even if group-transaction-events is enabled, due to a wrong configuration or under very high traffic conditions. For completeness sake, it would also be desirable to have batchesDistributed (given that batchesRedistributed and now batchesWithIncompleteTransactions) also published in the GatewaySenderMXBean. was: It would be interesting to have a counter called "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the number of batches sent with incomplete transactions. The reason is that it may not be guaranteed that all the events for a transaction will be sent in the same batch, even if group-transaction-events is enabled, due to a wrong configuration or under very high traffic conditions. > Publish batchesWithIncompleteTransactions in GatewaySenderMXBean > > > Key: GEODE-8783 > URL: https://issues.apache.org/jira/browse/GEODE-8783 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > It would be interesting to have a counter called > "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the > number of batches sent with incomplete transactions. > The reason is that it may not be guaranteed that all the events for a > transaction will be sent in the same batch, even if group-transaction-events > is enabled, due to a wrong configuration or under very high traffic > conditions. > For completeness sake, it would also be desirable to have batchesDistributed > (given that batchesRedistributed and now batchesWithIncompleteTransactions) > also published in the GatewaySenderMXBean. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[ https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez updated GEODE-8783: - Description: It would be interesting to have a counter called "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the number of batches sent with incomplete transactions. The reason is that it may not be guaranteed that all the events for a transaction will be sent in the same batch, even if group-transaction-events is enabled, due to a wrong configuration or under very high traffic conditions. It would be advisable to document this possibility and also relate it the new counter. For completeness sake, it would also be desirable to have batchesDistributed (given that batchesRedistributed and now batchesWithIncompleteTransactions) also published in the GatewaySenderMXBean. was: It would be interesting to have a counter called "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the number of batches sent with incomplete transactions. The reason is that it may not be guaranteed that all the events for a transaction will be sent in the same batch, even if group-transaction-events is enabled, due to a wrong configuration or under very high traffic conditions. For completeness sake, it would also be desirable to have batchesDistributed (given that batchesRedistributed and now batchesWithIncompleteTransactions) also published in the GatewaySenderMXBean. > Publish batchesWithIncompleteTransactions in GatewaySenderMXBean > > > Key: GEODE-8783 > URL: https://issues.apache.org/jira/browse/GEODE-8783 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > It would be interesting to have a counter called > "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the > number of batches sent with incomplete transactions. > The reason is that it may not be guaranteed that all the events for a > transaction will be sent in the same batch, even if group-transaction-events > is enabled, due to a wrong configuration or under very high traffic > conditions. > It would be advisable to document this possibility and also relate it the new > counter. > For completeness sake, it would also be desirable to have batchesDistributed > (given that batchesRedistributed and now batchesWithIncompleteTransactions) > also published in the GatewaySenderMXBean. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[ https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17248967#comment-17248967 ] ASF GitHub Bot commented on GEODE-8783: --- albertogpz opened a new pull request #5845: URL: https://github.com/apache/geode/pull/5845 …rMXBean 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 > Publish batchesWithIncompleteTransactions in GatewaySenderMXBean > > > Key: GEODE-8783 > URL: https://issues.apache.org/jira/browse/GEODE-8783 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > It would be interesting to have a counter called > "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the > number of batches sent with incomplete transactions. > The reason is that it may not be guaranteed that all the events for a > transaction will be sent in the same batch, even if group-transaction-events > is enabled, due to a wrong configuration or under very high traffic > conditions. > It would be advisable to document this possibility and also relate it the new > counter. > For completeness sake, it would also be desirable to have batchesDistributed > (given that batchesRedistributed and now batchesWithIncompleteTransactions) > also published in the GatewaySenderMXBean. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[ https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8783: -- Labels: pull-request-available (was: ) > Publish batchesWithIncompleteTransactions in GatewaySenderMXBean > > > Key: GEODE-8783 > URL: https://issues.apache.org/jira/browse/GEODE-8783 > Project: Geode > Issue Type: Improvement > Components: docs, jmx, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > It would be interesting to have a counter called > "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the > number of batches sent with incomplete transactions. > The reason is that it may not be guaranteed that all the events for a > transaction will be sent in the same batch, even if group-transaction-events > is enabled, due to a wrong configuration or under very high traffic > conditions. > It would be advisable to document this possibility and also relate it the new > counter. > For completeness sake, it would also be desirable to have batchesDistributed > (given that batchesRedistributed and now batchesWithIncompleteTransactions) > also published in the GatewaySenderMXBean. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7802) User Guide - add disclaimer that OQL queries are not pre-validated for nonexistent attributes
[ https://issues.apache.org/jira/browse/GEODE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249063#comment-17249063 ] Anilkumar Gingade commented on GEODE-7802: -- I don't understand this requirement. Even in case of other RDBMS query language, the existence of columns are determined either during query-compilation or query-execution time; and also for complex queries it can only determine the existence during execution time; that is what GEODE OQL engine is doing. One thing that could help to call out is; OQL query engine determines the field or methods on the object during query execution time. > User Guide - add disclaimer that OQL queries are not pre-validated for > nonexistent attributes > - > > Key: GEODE-7802 > URL: https://issues.apache.org/jira/browse/GEODE-7802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member @deepak khopade requests that we add a disclaimer to the > user guide stating that OQL queries are not pre-screened for references to > nonexistent attributes. The assertion is that users who have experience with > other query models may expect Geode to apply such validation. In the Geode > model, attributes and methods are resolved at runtime during query execution > - the server does not know what's actually stored in a region until the query > is executed. > The disclaimer could be added in one of two places: > Query Language Restrictions and Unsupported Features > ([https://geode.apache.org/docs/guide/111/developing/querying_basics/restrictions_and_unsupported_features.html]) > or > Querying FAQ and Examples > ([https://geode.apache.org/docs/guide/111/getting_started/querying_quick_reference.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7802) User Guide - add disclaimer that OQL queries are not pre-validated for nonexistent attributes
[ https://issues.apache.org/jira/browse/GEODE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249065#comment-17249065 ] ASF GitHub Bot commented on GEODE-7802: --- agingade commented on a change in pull request #5844: URL: https://github.com/apache/geode/pull/5844#discussion_r542493639 ## File path: geode-docs/developing/querying_basics/restrictions_and_unsupported_features.html.md.erb ## @@ -30,6 +30,6 @@ At a high level, <%=vars.product_name%> does not support the following querying - You cannot create an index on fields using Set/List types (Collection types) that are not comparable. The OQL index implementation expects fields to be Comparable. To workaround this, you can create a custom Collection type that implements Comparable. - ORDER BY is only supported with DISTINCT queries. - +- OQL queries aren't pre-validated for references to nonexistent methods and attributes. Review comment: I have commented on the ticket with my thoughts. What could be added here is, saying OQL query engine determines the field or methods on the given object (region keys and values) during query execution time. 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 - add disclaimer that OQL queries are not pre-validated for > nonexistent attributes > - > > Key: GEODE-7802 > URL: https://issues.apache.org/jira/browse/GEODE-7802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member @deepak khopade requests that we add a disclaimer to the > user guide stating that OQL queries are not pre-screened for references to > nonexistent attributes. The assertion is that users who have experience with > other query models may expect Geode to apply such validation. In the Geode > model, attributes and methods are resolved at runtime during query execution > - the server does not know what's actually stored in a region until the query > is executed. > The disclaimer could be added in one of two places: > Query Language Restrictions and Unsupported Features > ([https://geode.apache.org/docs/guide/111/developing/querying_basics/restrictions_and_unsupported_features.html]) > or > Querying FAQ and Examples > ([https://geode.apache.org/docs/guide/111/getting_started/querying_quick_reference.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8665) validate offline-disk-store command is missing information
[
https://issues.apache.org/jira/browse/GEODE-8665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249072#comment-17249072
]
ASF GitHub Bot commented on GEODE-8665:
---
agingade commented on a change in pull request #5801:
URL: https://github.com/apache/geode/pull/5801#discussion_r542497519
##
File path: geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java
##
@@ -2225,6 +2225,12 @@ long recoverCrf(OplogEntryIdSet deletedIds, boolean
recoverValues, boolean recov
if (getParent().isOfflineCompacting()) {
getParent().incLiveEntryCount(getRecoveryMap().size());
}
+long tc = totalCount.get();
+long tlc = totalLiveCount.get();
+if (getParent().isValidating() && tlc >= 0
+&& tc > tlc) {
Review comment:
Can there be a case where tc and tlc both are same number (including 0);
in that case dead-record-counts are 0; is this valid?
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
> validate offline-disk-store command is missing information
> --
>
> Key: GEODE-8665
> URL: https://issues.apache.org/jira/browse/GEODE-8665
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> According the document
> https://geode.apache.org/docs/guide/13/managing/disk_storage/validating_disk_store.html,
> `validate offline-disk-store` command should tell the number of records that
> would be removed if you compacted the store.
> For example, according to the document
> https://geode.apache.org/docs/guide/13/managing/disk_storage/compacting_disk_stores.html:
> ```
> gfsh>validate offline-disk-store --name=ds1 --disk-dirs=backupDirectory
> /root: entryCount=6
> /partitioned_region entryCount=1 bucketCount=10
> Disk store contains 12 compactable records.
> Total number of region entries in this disk store is: 7
> ```
> However, it does not show the number of records that would be removed if you
> compacted the store. Here is how to reproduce:
> 1. gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> 2. gfsh>put --key=1 --value=a --region=testRegion
> 3. gfsh>put --key=1 --value=b --region=testRegion
> 4. gfsh>put --key=1 --value=c --region=testRegion
> 5. gfsh>shutdown
> 6. gfsh>validate offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> expectedCrfs=[1]
> expectedDrfs=[1]
> dataSerializerIds=[]
> instantiatorIds= []
> /testRegion entryCount=1 bucketCount=1
> Total number of region entries in this disk store is: 1
> It should have shown something like: Disk store contains 2 compactable
> records.
> `compact offline-disk-store` command proves that there are 2 compactable
> records:
> gfsh>compact offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> Offline compaction removed 2 records.
> Cluster configuration service is not running. Configuration change is not
> persisted.
> `validate offline-disk-store` command could also show the wrong number of
> entries.
> 7. gfsh>put --key=2 --value=b --region=testRegion
> 8. gfsh>remove --region=/testRegion --key=1
> 9. gfsh>validate offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> expectedCrfs=[1]
> expectedDrfs=[1]
> dataSerializerIds=[]
> instantiatorIds= []
> /testRegion entryCount=2 bucketCount=2
> Total number of region entries in this disk store is: 2
> The correct number of entries should be 1, not 2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249117#comment-17249117 ] ASF GitHub Bot commented on GEODE-8577: --- jdeppe-pivotal opened a new pull request #5847: URL: https://github.com/apache/geode/pull/5847 - Could not reproduce after ~8000 runs - Added some debugging to dump 'docker ps' output if a connection cannot be obtained. 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 > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249122#comment-17249122
]
ASF GitHub Bot commented on GEODE-7739:
---
jhutchison commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r542554633
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -380,8 +384,10 @@ void addMemberArtifacts(InternalDistributedMember member) {
return;
}
- try {
+ FederatingManagerCancelCriterion cancelCriterion =
Review comment:
ok, maybe it makes most sense to wait wait until 5278 is pull merged,
and then adapt off that. @kirklund, Are you expecting to have time to get that
through in the near future?
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
> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members
> because of a race condition during startup. When ManagementCacheListener is
> first constructed, it is in a state that will ignore all callbacks because
> the field readyForEvents is false.
>
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started.
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently
> missing the personal mbeans of locator1.
> I think this is caused by some sort of race condition in the code that
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have
> mbeans for servers as well as other locators but I haven't seen a test case
> for this scenario.
> The exposure of this bug means that a user running more than one locator
> might have a locator that is missing one or more mbeans for the cluster.
>
> Studying the JMX code also reveals the existence of *GEODE-8012*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249121#comment-17249121
]
ASF GitHub Bot commented on GEODE-7739:
---
jhutchison commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r542554633
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -380,8 +384,10 @@ void addMemberArtifacts(InternalDistributedMember member) {
return;
}
- try {
+ FederatingManagerCancelCriterion cancelCriterion =
Review comment:
ok, maybe it makes most sense to wait wait until 5278 is pull merged,
and then adapt off that. Are you expecting to have time to get that through in
the near future?
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
> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members
> because of a race condition during startup. When ManagementCacheListener is
> first constructed, it is in a state that will ignore all callbacks because
> the field readyForEvents is false.
>
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started.
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently
> missing the personal mbeans of locator1.
> I think this is caused by some sort of race condition in the code that
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have
> mbeans for servers as well as other locators but I haven't seen a test case
> for this scenario.
> The exposure of this bug means that a user running more than one locator
> might have a locator that is missing one or more mbeans for the cluster.
>
> Studying the JMX code also reveals the existence of *GEODE-8012*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249132#comment-17249132
]
ASF GitHub Bot commented on GEODE-8780:
---
pivotal-eshu merged pull request #5837:
URL: https://github.com/apache/geode/pull/5837
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
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249135#comment-17249135
]
ASF subversion and git services commented on GEODE-8780:
Commit da898d7fabac82318a035d358463d9423f1b4e7b in geode's branch
refs/heads/develop from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=da898d7 ]
GEODE-8780: Increase the default number of function execution threads. (#5837)
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8766) dUnit Failure for Redis HashesIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249136#comment-17249136 ] ASF GitHub Bot commented on GEODE-8766: --- nonbinaryprogrammer merged pull request #5841: URL: https://github.com/apache/geode/pull/5841 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 > dUnit Failure for Redis HashesIntegrationTest > - > > Key: GEODE-8766 > URL: https://issues.apache.org/jira/browse/GEODE-8766 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: John Hutchison >Assignee: John Hutchison >Priority: Major > Labels: pull-request-available > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/610] > org.apache.geode.redis.internal.executor.hash.HashesIntegrationTest > > testConcurrentHGetAll FAILED > > org.junit.ComparisonFailure: expected:<[800]0L> but was:<[]0L> > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8766) dUnit Failure for Redis HashesIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249137#comment-17249137 ] ASF subversion and git services commented on GEODE-8766: Commit c766af09a3468a77225865357ad6c22fe9ce7174 in geode's branch refs/heads/develop from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c766af0 ] GEODE-8766: reduce collisions during hget in AbstractHashesIntegrationTest (#5841) * add retry logic if hset fails * remove (psuedo)randString method from test to avoid collisions Co-authored-by: john Hutchison > dUnit Failure for Redis HashesIntegrationTest > - > > Key: GEODE-8766 > URL: https://issues.apache.org/jira/browse/GEODE-8766 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: John Hutchison >Assignee: John Hutchison >Priority: Major > Labels: pull-request-available > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/610] > org.apache.geode.redis.internal.executor.hash.HashesIntegrationTest > > testConcurrentHGetAll FAILED > > org.junit.ComparisonFailure: expected:<[800]0L> but was:<[]0L> > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249145#comment-17249145 ] ASF GitHub Bot commented on GEODE-8728: --- demery-pivotal opened a new pull request #5848: URL: https://github.com/apache/geode/pull/5848 Do not review 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8728: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8766) dUnit Failure for Redis HashesIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison resolved GEODE-8766. --- Resolution: Fixed looks to be test issue. test code changed to reduce likelihood of collisions during test setup. https://github.com/apache/geode/pull/5841 > dUnit Failure for Redis HashesIntegrationTest > - > > Key: GEODE-8766 > URL: https://issues.apache.org/jira/browse/GEODE-8766 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: John Hutchison >Assignee: John Hutchison >Priority: Major > Labels: pull-request-available > > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/610] > org.apache.geode.redis.internal.executor.hash.HashesIntegrationTest > > testConcurrentHGetAll FAILED > > org.junit.ComparisonFailure: expected:<[800]0L> but was:<[]0L> > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-8780.
-
Resolution: Fixed
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8780) Current default number of function execution threads setting is rather low and could be increased
[
https://issues.apache.org/jira/browse/GEODE-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-8780:
Fix Version/s: 1.14.0
> Current default number of function execution threads setting is rather low
> and could be increased
> -
>
> Key: GEODE-8780
> URL: https://issues.apache.org/jira/browse/GEODE-8780
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The default number of function execution threads setting is 16 or based on
> the number of processors.
> int MAX_FE_THREADS = Integer.getInteger("DistributionManager.MAX_FE_THREADS",
> Math.max(Runtime.getRuntime().availableProcessors() * 4, 16));
> If not enough function thread is available, a new function execution thread
> is created after 5 seconds wait to handle the function execution request. It
> is better to have this default to be increased.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249164#comment-17249164
]
ASF GitHub Bot commented on GEODE-8782:
---
jinmeiliao commented on pull request #5840:
URL: https://github.com/apache/geode/pull/5840#issuecomment-744603610
I see you are binding the subject to the threads running the function and
also adding the the parameter `principal` to the constructor of the
`FunctoinContext`, I wonder if we only need to do one of the two? If subject is
already in the thread context, you don't need to pass it in the constructor,
you can just directly get it from the thread local by calling
`getCache().getSecurityService().getPrinicipal()`
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 getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[
https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249177#comment-17249177
]
ASF GitHub Bot commented on GEODE-8783:
---
DonalEvans commented on a change in pull request #5845:
URL: https://github.com/apache/geode/pull/5845#discussion_r542575827
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
##
@@ -1354,6 +1355,7 @@ private void
peekEventsFromIncompleteTransactions(List b
return;
}
+boolean areAllEventsForTransactionsInBatch = true;
Review comment:
The name of this variable is too similar to the already existing
`areAllEventsForTransactionInBatch`, which is confusing. Please rename one or
both of them to make it clearer what they are keeping track of.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderStats.java
##
@@ -240,6 +246,9 @@ protected static StatisticsType createType(final
StatisticsTypeFactory f, final
f.createIntCounter(BATCHES_REDISTRIBUTED,
"Number of batches of events removed from the event queue and
resent.",
"operations", false),
+f.createIntCounter(BATCHES_WITH_INCOMPLETE_TRANSACTIONS,
+"Number of batches of events sent with incomplete
transactions.",
+"operations", false),
Review comment:
The `createIntCounter()` method is deprecated. As per the javadocs on
the method, `createLongCounter()` should be used instead.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
##
@@ -486,6 +486,7 @@ private void
peekEventsFromIncompleteTransactions(List> batch,
return;
}
+boolean areAllEventsForTransactionsInBatch = true;
Review comment:
The name of this variable is too similar to the already existing
areAllEventsForTransactionInBatch, which is confusing. Please rename one or
both of them to make it clearer what they are keeping track of.
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
##
@@ -467,8 +467,66 @@ public void
testPRParallelPropagationWithGroupTransactionEventsSendsBatchesWithC
assertEquals(0, v4List.get(5) + v5List.get(5) + v6List.get(5) +
v7List.get(5));
// events not queued conflated:
assertEquals(0, v4List.get(7) + v5List.get(7) + v6List.get(7) +
v7List.get(7));
+// batches with incomplete transactions
+assertEquals(0, (int) v4List.get(13));
+
+ }
+
+ @Test
+ public void
testPRParallelPropagationWithGroupTransactionEventsWithIncompleteTransactions()
{
+Integer lnPort = vm0.invoke(() ->
WANTestBase.createFirstLocatorWithDSId(1));
+Integer nyPort = vm1.invoke(() -> WANTestBase.createFirstRemoteLocator(2,
lnPort));
+
+createCacheInVMs(nyPort, vm2);
+createReceiverInVMs(vm2);
+
+int dispThreads = 2;
+createSenderInVm(lnPort, vm4, dispThreads);
+
+createReceiverPR(vm2, 0);
+
+createSenderPRInVM(0, vm4);
+
+startSenderInVMs("ln", vm4);
+
+// Adding events in transactions
+final Map keyValue = new HashMap<>();
+int entries = 30;
+for (int i = 0; i < entries; i++) {
+ keyValue.put(i, i);
+}
+
+int entriesPerTransaction = 3;
+vm4.invoke(
+() -> WANTestBase.doPutsInsideTransactions(testName, keyValue,
entriesPerTransaction));
+
+vm4.invoke(() -> WANTestBase.validateRegionSize(testName, entries));
+
+ArrayList v4List =
+(ArrayList) vm4.invoke(() -> WANTestBase.getSenderStats("ln",
0));
+
+int batches = 4;
Review comment:
It's not clear to me where this value is coming from. How do we know
that we expect 4 batches with incomplete transactions here?
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
> Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
>
>
> Key: GEODE-8783
> URL: https://issues.apache.org/jira/browse/GEODE-8783
> Project: Geode
> Issue Type: Improvement
> Components: docs, jmx, wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> It would be interesting to have a counter called
> "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the
> number of batches sent with incomplete transactions.
> The reason is that
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249183#comment-17249183 ] ASF GitHub Bot commented on GEODE-8728: --- lgtm-com[bot] commented on pull request #5848: URL: https://github.com/apache/geode/pull/5848#issuecomment-744613804 This pull request **fixes 1 alert** when merging 21d3bdb32a4afddaf50847ad7a700e62422152a5 into c766af09a3468a77225865357ad6c22fe9ce7174 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-f546941956014205576c3a9d7853291728213433) **fixed alerts:** * 1 for Dereferenced variable may be null 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249205#comment-17249205
]
ASF GitHub Bot commented on GEODE-7739:
---
kirklund commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r542621525
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -380,8 +384,10 @@ void addMemberArtifacts(InternalDistributedMember member) {
return;
}
- try {
+ FederatingManagerCancelCriterion cancelCriterion =
Review comment:
I hope to have #5728 ready to merge today at the soonest or in a day or
two.
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
> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members
> because of a race condition during startup. When ManagementCacheListener is
> first constructed, it is in a state that will ignore all callbacks because
> the field readyForEvents is false.
>
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started.
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently
> missing the personal mbeans of locator1.
> I think this is caused by some sort of race condition in the code that
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have
> mbeans for servers as well as other locators but I haven't seen a test case
> for this scenario.
> The exposure of this bug means that a user running more than one locator
> might have a locator that is missing one or more mbeans for the cluster.
>
> Studying the JMX code also reveals the existence of *GEODE-8012*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249208#comment-17249208
]
ASF GitHub Bot commented on GEODE-7739:
---
kirklund commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r542625730
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -380,8 +384,10 @@ void addMemberArtifacts(InternalDistributedMember member) {
return;
}
- try {
+ FederatingManagerCancelCriterion cancelCriterion =
Review comment:
@jdeppe-pivotal hmm, well now you have me second-guessing the need for
CancelCriterion. Maybe we can get another review before we make more changes on
this PR.
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
> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members
> because of a race condition during startup. When ManagementCacheListener is
> first constructed, it is in a state that will ignore all callbacks because
> the field readyForEvents is false.
>
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started.
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently
> missing the personal mbeans of locator1.
> I think this is caused by some sort of race condition in the code that
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have
> mbeans for servers as well as other locators but I haven't seen a test case
> for this scenario.
> The exposure of this bug means that a user running more than one locator
> might have a locator that is missing one or more mbeans for the cluster.
>
> Studying the JMX code also reveals the existence of *GEODE-8012*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249211#comment-17249211
]
ASF GitHub Bot commented on GEODE-7739:
---
kirklund commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r542625730
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/FederatingManager.java
##
@@ -380,8 +384,10 @@ void addMemberArtifacts(InternalDistributedMember member) {
return;
}
- try {
+ FederatingManagerCancelCriterion cancelCriterion =
Review comment:
@jdeppe-pivotal hmm, well now you have me second-guessing the need for
CancelCriterion. Maybe we can get another review before we make more changes on
this PR. EDIT: if we don't don't need the Cache's CancelCriterion, then we
don't need to use any Stoppable* classes either.
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
> JMX managers may fail to federate mbeans for other members
> --
>
> Key: GEODE-7739
> URL: https://issues.apache.org/jira/browse/GEODE-7739
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> JMX Manager may fail to federate one or more MXBeans for other members
> because of a race condition during startup. When ManagementCacheListener is
> first constructed, it is in a state that will ignore all callbacks because
> the field readyForEvents is false.
>
> Debugging with JMXMBeanReconnectDUnitTest revealed this bug.
> The test starts two locators with jmx manager configured and started.
> Locator1 always has all of locator2's mbeans, but locator2 is intermittently
> missing the personal mbeans of locator1.
> I think this is caused by some sort of race condition in the code that
> creates the monitoring regions for other members in locator2.
> It's possible that the jmx manager that hits this bug might fail to have
> mbeans for servers as well as other locators but I haven't seen a test case
> for this scenario.
> The exposure of this bug means that a user running more than one locator
> might have a locator that is missing one or more mbeans for the cluster.
>
> Studying the JMX code also reveals the existence of *GEODE-8012*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[
https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249218#comment-17249218
]
ASF GitHub Bot commented on GEODE-8783:
---
albertogpz commented on a change in pull request #5845:
URL: https://github.com/apache/geode/pull/5845#discussion_r542635697
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
##
@@ -467,8 +467,66 @@ public void
testPRParallelPropagationWithGroupTransactionEventsSendsBatchesWithC
assertEquals(0, v4List.get(5) + v5List.get(5) + v6List.get(5) +
v7List.get(5));
// events not queued conflated:
assertEquals(0, v4List.get(7) + v5List.get(7) + v6List.get(7) +
v7List.get(7));
+// batches with incomplete transactions
+assertEquals(0, (int) v4List.get(13));
+
+ }
+
+ @Test
+ public void
testPRParallelPropagationWithGroupTransactionEventsWithIncompleteTransactions()
{
+Integer lnPort = vm0.invoke(() ->
WANTestBase.createFirstLocatorWithDSId(1));
+Integer nyPort = vm1.invoke(() -> WANTestBase.createFirstRemoteLocator(2,
lnPort));
+
+createCacheInVMs(nyPort, vm2);
+createReceiverInVMs(vm2);
+
+int dispThreads = 2;
+createSenderInVm(lnPort, vm4, dispThreads);
+
+createReceiverPR(vm2, 0);
+
+createSenderPRInVM(0, vm4);
+
+startSenderInVMs("ln", vm4);
+
+// Adding events in transactions
+final Map keyValue = new HashMap<>();
+int entries = 30;
+for (int i = 0; i < entries; i++) {
+ keyValue.put(i, i);
+}
+
+int entriesPerTransaction = 3;
+vm4.invoke(
+() -> WANTestBase.doPutsInsideTransactions(testName, keyValue,
entriesPerTransaction));
+
+vm4.invoke(() -> WANTestBase.validateRegionSize(testName, entries));
+
+ArrayList v4List =
+(ArrayList) vm4.invoke(() -> WANTestBase.getSenderStats("ln",
0));
+
+int batches = 4;
Review comment:
Very good question. I will try to clarify it in a comment in the test
case.
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
> Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
>
>
> Key: GEODE-8783
> URL: https://issues.apache.org/jira/browse/GEODE-8783
> Project: Geode
> Issue Type: Improvement
> Components: docs, jmx, wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> It would be interesting to have a counter called
> "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the
> number of batches sent with incomplete transactions.
> The reason is that it may not be guaranteed that all the events for a
> transaction will be sent in the same batch, even if group-transaction-events
> is enabled, due to a wrong configuration or under very high traffic
> conditions.
> It would be advisable to document this possibility and also relate it the new
> counter.
> For completeness sake, it would also be desirable to have batchesDistributed
> (given that batchesRedistributed and now batchesWithIncompleteTransactions)
> also published in the GatewaySenderMXBean.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249244#comment-17249244 ] ASF GitHub Bot commented on GEODE-8728: --- lgtm-com[bot] commented on pull request #5848: URL: https://github.com/apache/geode/pull/5848#issuecomment-744654595 This pull request **fixes 1 alert** when merging b96249b29fe81719db57229a867d2ac47c6c6499 into c766af09a3468a77225865357ad6c22fe9ce7174 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-4624847efbfc79b0003be5f82870c244da4b5fd6) **fixed alerts:** * 1 for Dereferenced variable may be null 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8782) Add getPrincipal method to FunctionContext interface
[
https://issues.apache.org/jira/browse/GEODE-8782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249255#comment-17249255
]
ASF GitHub Bot commented on GEODE-8782:
---
upthewaterspout commented on a change in pull request #5840:
URL: https://github.com/apache/geode/pull/5840#discussion_r542691265
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/execute/FunctionRemoteContext.java
##
@@ -84,6 +85,10 @@ public void fromData(DataInput in) throws IOException,
ClassNotFoundException {
this.bucketArray = BucketSetHelper.fromSet(bucketSet);
}
this.isReExecute = DataSerializer.readBoolean(in);
+
+if
(StaticSerialization.getVersionForDataStream(in).isNotOlderThan(KnownVersion.GEODE_1_14_0))
{
Review comment:
Instead of this, I think you could make this class implement
VersionedDataSerializable which might handle writing the principal differently.
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 getPrincipal method to FunctionContext interface
>
>
> Key: GEODE-8782
> URL: https://issues.apache.org/jira/browse/GEODE-8782
> Project: Geode
> Issue Type: New Feature
> Components: core
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> In some cases it would be very helpful to have access to the {{Principal}}
> when executing a function.
> It may seem obvious that if one has a reference to the {{cache}} that you
> could get to the {{SecurityManager}} and extract the {{Subject}} and thus the
> {{Principal}} from there. However, in some cases, Geode will seamlessly proxy
> a function call from one server to the other. This will typically happen with
> {{onRegion}} calls and partitioned regions. In such cases, the security
> context is lost and thus the principal is not accessible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8769) CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > clientsStat_withConnectAndClose_isCorrect FAILED
[ https://issues.apache.org/jira/browse/GEODE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249258#comment-17249258 ] ASF GitHub Bot commented on GEODE-8769: --- jhutchison opened a new pull request #5849: URL: https://github.com/apache/geode/pull/5849 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 > CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > > > Key: GEODE-8769 > URL: https://issues.apache.org/jira/browse/GEODE-8769 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/592 > org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.redis.internal.RedisStatsIntegrationTest expected:<[0]L> but > was:<[-2]L> within 2 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.clientsStat_withConnectAndClose_isCorrect(RedisStatsIntegrationTest.java:484) > Caused by: > org.junit.ComparisonFailure: expected:<[0]L> but was:<[-2]L> > at sun.reflect.GeneratedConstructorAccessor31.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.lambda$clientsStat_withConnectAndClose_isCorrect$4(RedisStatsIntegrationTest.java:484) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8769) CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > clientsStat_withConnectAndClose_isCorrect FAILED
[ https://issues.apache.org/jira/browse/GEODE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249259#comment-17249259 ] ASF GitHub Bot commented on GEODE-8769: --- jhutchison commented on pull request #5818: URL: https://github.com/apache/geode/pull/5818#issuecomment-744672280 re-submitted under https://github.com/apache/geode/pull/5849 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 > CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > > > Key: GEODE-8769 > URL: https://issues.apache.org/jira/browse/GEODE-8769 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/592 > org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.redis.internal.RedisStatsIntegrationTest expected:<[0]L> but > was:<[-2]L> within 2 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.clientsStat_withConnectAndClose_isCorrect(RedisStatsIntegrationTest.java:484) > Caused by: > org.junit.ComparisonFailure: expected:<[0]L> but was:<[-2]L> > at sun.reflect.GeneratedConstructorAccessor31.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.lambda$clientsStat_withConnectAndClose_isCorrect$4(RedisStatsIntegrationTest.java:484) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249263#comment-17249263 ] ASF subversion and git services commented on GEODE-8577: Commit d8e1b72b6a84da8e2cd5e912a435e609933fbe98 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d8e1b72 ] GEODE-8577: Re-enable PubSubNativeRedisAcceptanceTest (#5847) - Could not reproduce after ~8000 runs - Added some debugging to dump 'docker ps' output if a connection cannot be obtained. Authored-by: Jens Deppe > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8769) CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > clientsStat_withConnectAndClose_isCorrect FAILED
[ https://issues.apache.org/jira/browse/GEODE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249265#comment-17249265 ] ASF GitHub Bot commented on GEODE-8769: --- jdeppe-pivotal commented on pull request #5818: URL: https://github.com/apache/geode/pull/5818#issuecomment-744672934 Closing in favor of: https://github.com/apache/geode/pull/5849 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 > CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > > > Key: GEODE-8769 > URL: https://issues.apache.org/jira/browse/GEODE-8769 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/592 > org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.redis.internal.RedisStatsIntegrationTest expected:<[0]L> but > was:<[-2]L> within 2 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.clientsStat_withConnectAndClose_isCorrect(RedisStatsIntegrationTest.java:484) > Caused by: > org.junit.ComparisonFailure: expected:<[0]L> but was:<[-2]L> > at sun.reflect.GeneratedConstructorAccessor31.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.lambda$clientsStat_withConnectAndClose_isCorrect$4(RedisStatsIntegrationTest.java:484) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8769) CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > clientsStat_withConnectAndClose_isCorrect FAILED
[ https://issues.apache.org/jira/browse/GEODE-8769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249264#comment-17249264 ] ASF GitHub Bot commented on GEODE-8769: --- jdeppe-pivotal closed pull request #5818: URL: https://github.com/apache/geode/pull/5818 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 > CI Failure: org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > > > Key: GEODE-8769 > URL: https://issues.apache.org/jira/browse/GEODE-8769 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK8/builds/592 > org.apache.geode.redis.internal.RedisStatsIntegrationTest > > clientsStat_withConnectAndClose_isCorrect FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.redis.internal.RedisStatsIntegrationTest expected:<[0]L> but > was:<[-2]L> within 2 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.clientsStat_withConnectAndClose_isCorrect(RedisStatsIntegrationTest.java:484) > Caused by: > org.junit.ComparisonFailure: expected:<[0]L> but was:<[-2]L> > at sun.reflect.GeneratedConstructorAccessor31.newInstance(Unknown > Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.RedisStatsIntegrationTest.lambda$clientsStat_withConnectAndClose_isCorrect$4(RedisStatsIntegrationTest.java:484) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8783) Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
[
https://issues.apache.org/jira/browse/GEODE-8783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249266#comment-17249266
]
ASF GitHub Bot commented on GEODE-8783:
---
DonalEvans commented on a change in pull request #5845:
URL: https://github.com/apache/geode/pull/5845#discussion_r542710577
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
##
@@ -467,8 +467,66 @@ public void
testPRParallelPropagationWithGroupTransactionEventsSendsBatchesWithC
assertEquals(0, v4List.get(5) + v5List.get(5) + v6List.get(5) +
v7List.get(5));
// events not queued conflated:
assertEquals(0, v4List.get(7) + v5List.get(7) + v6List.get(7) +
v7List.get(7));
+// batches with incomplete transactions
+assertEquals(0, (int) v4List.get(13));
+
+ }
+
+ @Test
+ public void
testPRParallelPropagationWithGroupTransactionEventsWithIncompleteTransactions()
{
+Integer lnPort = vm0.invoke(() ->
WANTestBase.createFirstLocatorWithDSId(1));
+Integer nyPort = vm1.invoke(() -> WANTestBase.createFirstRemoteLocator(2,
lnPort));
+
+createCacheInVMs(nyPort, vm2);
+createReceiverInVMs(vm2);
+
+int dispThreads = 2;
+createSenderInVm(lnPort, vm4, dispThreads);
+
+createReceiverPR(vm2, 0);
+
+createSenderPRInVM(0, vm4);
+
+startSenderInVMs("ln", vm4);
+
+// Adding events in transactions
+final Map keyValue = new HashMap<>();
+int entries = 30;
+for (int i = 0; i < entries; i++) {
+ keyValue.put(i, i);
+}
+
+int entriesPerTransaction = 3;
+vm4.invoke(
+() -> WANTestBase.doPutsInsideTransactions(testName, keyValue,
entriesPerTransaction));
+
+vm4.invoke(() -> WANTestBase.validateRegionSize(testName, entries));
+
+ArrayList v4List =
+(ArrayList) vm4.invoke(() -> WANTestBase.getSenderStats("ln",
0));
+
+int batches = 4;
Review comment:
I looked at the test a bit closer and now see that the batch size is set
as 10 in the `createSenderInVm()` method, so it might be good to add a comment
explaining that 4 batches are expected because each dispatcher thread will send
2 batches, since it's not immediately obvious when looking at the test what the
batch size is, or why 30 entries with a batch size of 10 would result in 4
batches rather than 3.
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
> Publish batchesWithIncompleteTransactions in GatewaySenderMXBean
>
>
> Key: GEODE-8783
> URL: https://issues.apache.org/jira/browse/GEODE-8783
> Project: Geode
> Issue Type: Improvement
> Components: docs, jmx, wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> It would be interesting to have a counter called
> "batchesWithIncompleteTransactions" in the GatewaySenderMXBean that shows the
> number of batches sent with incomplete transactions.
> The reason is that it may not be guaranteed that all the events for a
> transaction will be sent in the same batch, even if group-transaction-events
> is enabled, due to a wrong configuration or under very high traffic
> conditions.
> It would be advisable to document this possibility and also relate it the new
> counter.
> For completeness sake, it would also be desirable to have batchesDistributed
> (given that batchesRedistributed and now batchesWithIncompleteTransactions)
> also published in the GatewaySenderMXBean.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8577) PubSubNativeRedisAcceptanceTest is flaky
[ https://issues.apache.org/jira/browse/GEODE-8577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249260#comment-17249260 ] ASF GitHub Bot commented on GEODE-8577: --- jdeppe-pivotal merged pull request #5847: URL: https://github.com/apache/geode/pull/5847 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 > PubSubNativeRedisAcceptanceTest is flaky > > > Key: GEODE-8577 > URL: https://issues.apache.org/jira/browse/GEODE-8577 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Going to disable this one test and work on fixing that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249269#comment-17249269 ] ASF GitHub Bot commented on GEODE-8781: --- boglesby merged pull request #5838: URL: https://github.com/apache/geode/pull/5838 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 > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249270#comment-17249270 ] ASF subversion and git services commented on GEODE-8781: Commit bda0d3fbf13ebdf37db8d710cf7f4d4b892a1646 in geode's branch refs/heads/develop from Barry Oglesby [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bda0d3f ] GEODE-8781: Added ReconnectListener to PeerToPeerSessionCache > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8784) Create matching Geode stats for all Redis INFO stats
John Hutchison created GEODE-8784: - Summary: Create matching Geode stats for all Redis INFO stats Key: GEODE-8784 URL: https://issues.apache.org/jira/browse/GEODE-8784 Project: Geode Issue Type: Bug Components: redis Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby reassigned GEODE-8781: -- Assignee: Barrett Oglesby > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8781) The Tomcat session state module in P2P mode doesn't re-establish the session region after a reconnect
[ https://issues.apache.org/jira/browse/GEODE-8781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrett Oglesby resolved GEODE-8781. Resolution: Fixed > The Tomcat session state module in P2P mode doesn't re-establish the session > region after a reconnect > - > > Key: GEODE-8781 > URL: https://issues.apache.org/jira/browse/GEODE-8781 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Barrett Oglesby >Assignee: Barrett Oglesby >Priority: Major > Labels: pull-request-available > > In the PeerToPeerSessionCache, the createOrRetrieveRegion method creates the > region when the Tomcat server is started. > The PeerToPeerSessionCache stores this region in a field called > sessionRegion. It also stores the cache in a field called cache, and the > fronting region in a field called operatingRegion if local caching is enabled. > When the DistributedSystem is disconnected, the cache and its regions are > closed. > When the DistributedSystem is reconnected, the cache is recreated but not the > regions. This is because they were created using API rather than in XML or > cluster configuration. This can be changed by setting > use-cluster-configuration=false, but it won't really make a difference. > Thats because the PeerToPeerSessionCache's references are to the closed cache > and regions. > Adding a ReconnectListener to the PeerToPeerSessionCache so that these > references are re-established will address this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-8573:
---
Fix Version/s: 1.14.0
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.14.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag resolved GEODE-8573.
Resolution: Fixed
This has been fixed with a commit for GEODE-8745
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag closed GEODE-8573.
--
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
> Fix For: 1.14.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8153) Replace ACE_Sock with boost::asio in TcpSslConn
[ https://issues.apache.org/jira/browse/GEODE-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249301#comment-17249301 ] ASF subversion and git services commented on GEODE-8153: Commit 50a441c4c0f78679558d520eaf20022ae51de3ff in geode-native's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=50a441c ] GEODE-8152, GEODE-8153: replace ACE sockets with boost/asio (#697) Co-authored-by: Matthew Reddington > Replace ACE_Sock with boost::asio in TcpSslConn > --- > > Key: GEODE-8153 > URL: https://issues.apache.org/jira/browse/GEODE-8153 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Priority: Major > > Why > Over the course of time, we are gradually working to get rid of the NC > dependency on ACE > As a native client developer > I want to be able to build without ACE > To improve the maintainability of the code, since ACE isn't really supported > actively and is quite old and obscure > Acceptance Criteria > Sockets code is using boost::asio rather than ACE. All integration tests are > passing on all platforms > Scenario: > Given a branch with ACE_Sock replaced with boost::asio in TcpConn and > TcpSslConn > When I deploy an NC pipeline for that branch > Then the CI completes with all tests passing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8152) Replace ACE_Sock with boost::asio in TcpConn
[
https://issues.apache.org/jira/browse/GEODE-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249300#comment-17249300
]
ASF subversion and git services commented on GEODE-8152:
Commit 50a441c4c0f78679558d520eaf20022ae51de3ff in geode-native's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=50a441c ]
GEODE-8152, GEODE-8153: replace ACE sockets with boost/asio (#697)
Co-authored-by: Matthew Reddington
> Replace ACE_Sock with boost::asio in TcpConn
>
>
> Key: GEODE-8152
> URL: https://issues.apache.org/jira/browse/GEODE-8152
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> h3. Why
> Over the course of time, we are gradually working to get rid of the NC
> dependency on ACE
> *As a native client developer*
> *I want to be able to build without ACE*
> *To improve the maintainability of the code, since ACE isn't really supported
> actively and is quite old and obscure*
> h3. Acceptance Criteria
> Sockets code is using boost::asio rather than ACE. All integration tests are
> passing on all platforms
>
> {{Scenario: Given a branch with ACE_Sock replaced with boost::asio in
> TcpConnWhen I build locally and run integration tests
> All "plain socket", i.e. non-SSL, tests pass}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8152) Replace ACE_Sock with boost::asio in TcpConn
[
https://issues.apache.org/jira/browse/GEODE-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-8152.
-
Resolution: Fixed
> Replace ACE_Sock with boost::asio in TcpConn
>
>
> Key: GEODE-8152
> URL: https://issues.apache.org/jira/browse/GEODE-8152
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> h3. Why
> Over the course of time, we are gradually working to get rid of the NC
> dependency on ACE
> *As a native client developer*
> *I want to be able to build without ACE*
> *To improve the maintainability of the code, since ACE isn't really supported
> actively and is quite old and obscure*
> h3. Acceptance Criteria
> Sockets code is using boost::asio rather than ACE. All integration tests are
> passing on all platforms
>
> {{Scenario: Given a branch with ACE_Sock replaced with boost::asio in
> TcpConnWhen I build locally and run integration tests
> All "plain socket", i.e. non-SSL, tests pass}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8153) Replace ACE_Sock with boost::asio in TcpSslConn
[ https://issues.apache.org/jira/browse/GEODE-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-8153. --- > Replace ACE_Sock with boost::asio in TcpSslConn > --- > > Key: GEODE-8153 > URL: https://issues.apache.org/jira/browse/GEODE-8153 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Priority: Major > > Why > Over the course of time, we are gradually working to get rid of the NC > dependency on ACE > As a native client developer > I want to be able to build without ACE > To improve the maintainability of the code, since ACE isn't really supported > actively and is quite old and obscure > Acceptance Criteria > Sockets code is using boost::asio rather than ACE. All integration tests are > passing on all platforms > Scenario: > Given a branch with ACE_Sock replaced with boost::asio in TcpConn and > TcpSslConn > When I deploy an NC pipeline for that branch > Then the CI completes with all tests passing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8152) Replace ACE_Sock with boost::asio in TcpConn
[
https://issues.apache.org/jira/browse/GEODE-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-8152.
---
> Replace ACE_Sock with boost::asio in TcpConn
>
>
> Key: GEODE-8152
> URL: https://issues.apache.org/jira/browse/GEODE-8152
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> h3. Why
> Over the course of time, we are gradually working to get rid of the NC
> dependency on ACE
> *As a native client developer*
> *I want to be able to build without ACE*
> *To improve the maintainability of the code, since ACE isn't really supported
> actively and is quite old and obscure*
> h3. Acceptance Criteria
> Sockets code is using boost::asio rather than ACE. All integration tests are
> passing on all platforms
>
> {{Scenario: Given a branch with ACE_Sock replaced with boost::asio in
> TcpConnWhen I build locally and run integration tests
> All "plain socket", i.e. non-SSL, tests pass}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8153) Replace ACE_Sock with boost::asio in TcpSslConn
[ https://issues.apache.org/jira/browse/GEODE-8153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-8153. - Resolution: Fixed > Replace ACE_Sock with boost::asio in TcpSslConn > --- > > Key: GEODE-8153 > URL: https://issues.apache.org/jira/browse/GEODE-8153 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Priority: Major > > Why > Over the course of time, we are gradually working to get rid of the NC > dependency on ACE > As a native client developer > I want to be able to build without ACE > To improve the maintainability of the code, since ACE isn't really supported > actively and is quite old and obscure > Acceptance Criteria > Sockets code is using boost::asio rather than ACE. All integration tests are > passing on all platforms > Scenario: > Given a branch with ACE_Sock replaced with boost::asio in TcpConn and > TcpSslConn > When I deploy an NC pipeline for that branch > Then the CI completes with all tests passing -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8665) validate offline-disk-store command is missing information
[
https://issues.apache.org/jira/browse/GEODE-8665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249327#comment-17249327
]
ASF GitHub Bot commented on GEODE-8665:
---
jchen21 commented on a change in pull request #5801:
URL: https://github.com/apache/geode/pull/5801#discussion_r542812368
##
File path: geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java
##
@@ -2225,6 +2225,12 @@ long recoverCrf(OplogEntryIdSet deletedIds, boolean
recoverValues, boolean recov
if (getParent().isOfflineCompacting()) {
getParent().incLiveEntryCount(getRecoveryMap().size());
}
+long tc = totalCount.get();
+long tlc = totalLiveCount.get();
+if (getParent().isValidating() && tlc >= 0
+&& tc > tlc) {
Review comment:
Yes. It is valid. It is very common for tc(totalCount) and
tlc(totalLiveCount) to be the same value, including 0, which indicates an empty
Oplog. When tc and tlc are the same, offline disk store validation will not
show any message about the number of records that would be removed if you
compacted the store, since there is no deleted or skipped entry in this case.
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
> validate offline-disk-store command is missing information
> --
>
> Key: GEODE-8665
> URL: https://issues.apache.org/jira/browse/GEODE-8665
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> According the document
> https://geode.apache.org/docs/guide/13/managing/disk_storage/validating_disk_store.html,
> `validate offline-disk-store` command should tell the number of records that
> would be removed if you compacted the store.
> For example, according to the document
> https://geode.apache.org/docs/guide/13/managing/disk_storage/compacting_disk_stores.html:
> ```
> gfsh>validate offline-disk-store --name=ds1 --disk-dirs=backupDirectory
> /root: entryCount=6
> /partitioned_region entryCount=1 bucketCount=10
> Disk store contains 12 compactable records.
> Total number of region entries in this disk store is: 7
> ```
> However, it does not show the number of records that would be removed if you
> compacted the store. Here is how to reproduce:
> 1. gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> 2. gfsh>put --key=1 --value=a --region=testRegion
> 3. gfsh>put --key=1 --value=b --region=testRegion
> 4. gfsh>put --key=1 --value=c --region=testRegion
> 5. gfsh>shutdown
> 6. gfsh>validate offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> expectedCrfs=[1]
> expectedDrfs=[1]
> dataSerializerIds=[]
> instantiatorIds= []
> /testRegion entryCount=1 bucketCount=1
> Total number of region entries in this disk store is: 1
> It should have shown something like: Disk store contains 2 compactable
> records.
> `compact offline-disk-store` command proves that there are 2 compactable
> records:
> gfsh>compact offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> Offline compaction removed 2 records.
> Cluster configuration service is not running. Configuration change is not
> persisted.
> `validate offline-disk-store` command could also show the wrong number of
> entries.
> 7. gfsh>put --key=2 --value=b --region=testRegion
> 8. gfsh>remove --region=/testRegion --key=1
> 9. gfsh>validate offline-disk-store --name=DEFAULT
> --disk-dirs=/Users/jchen/workspace/geode/geode-assembly/build/install/apache-geode/server1
> expectedCrfs=[1]
> expectedDrfs=[1]
> dataSerializerIds=[]
> instantiatorIds= []
> /testRegion entryCount=2 bucketCount=2
> Total number of region entries in this disk store is: 2
> The correct number of entries should be 1, not 2.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8785) Geode Client Reconnect and cache incosistency during that preiod
Leon Finker created GEODE-8785:
--
Summary: Geode Client Reconnect and cache incosistency during that
preiod
Key: GEODE-8785
URL: https://issues.apache.org/jira/browse/GEODE-8785
Project: Geode
Issue Type: Bug
Components: client/server
Reporter: Leon Finker
Hi,
We observed an issue with geode client re-connection and cache synchronization.
We have a caching client region. In this region we register interest for keys
(could be .*). Now, when client is reconnecting with the server, at that exact
period, client region loses it's data. That's until it is repopulated again
with interest registration calls and cache sync up. Looking
QueueManagerImpl.recoverSingleKey,
and when primary endpoint recovered, it
issues Region.clearKeysOfInterest then eventually calls
case InterestType.KEY:
if (key instanceof String && key.equals("ALL_KEYS")) {
clearViaRegEx(".*");
...
for (Object o : entrySet(false)) {
...
localDestroyNoCallbacks(entryKey);
This is really unexpected behavior and impossible to deal with. Everyone
would have to either create local disconnected region paired with proxy
empty region and forward events. Or always call keySetOnServer.
In addition, there is no way to know that the region is in this intermediate
state. There is kind of cache global callback, but that's too global:
{color:#cc7832}private void
{color}{color:#ffc66d}recoverAllInterestTypes{color}({color:#cc7832}final
{color}Connection recoveredConnection{color:#cc7832},
{color}{color:#cc7832} boolean {color}isFirstNewConnection) {
{color:#cc7832}if
{color}(PoolImpl.{color:#9876aa}BEFORE_RECOVER_INTEREST_CALLBACK_FLAG{color}) {
ClientServerObserver bo =
ClientServerObserverHolder.getInstance(){color:#cc7832};
{color} bo.beforeInterestRecovery(){color:#cc7832};
{color} }
What can be done to solve this race condition of not having expected data or
having incomplete cache data?
Thank you
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8786) INFO command hit/miss ratios should match native Redis
Raymond Ingles created GEODE-8786: - Summary: INFO command hit/miss ratios should match native Redis Key: GEODE-8786 URL: https://issues.apache.org/jira/browse/GEODE-8786 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.14.0 Reporter: Raymond Ingles Current hit/miss ratios for Geode Redis stats do not match those for native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8787) CI Failure: PubSubNativeRedisAcceptanceTest.ensureOrderingOfPublishedMessages FAILED
Eric Shu created GEODE-8787:
---
Summary: CI Failure:
PubSubNativeRedisAcceptanceTest.ensureOrderingOfPublishedMessages FAILED
Key: GEODE-8787
URL: https://issues.apache.org/jira/browse/GEODE-8787
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Eric Shu
Test run failed:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/631
{noformat}
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Tried 10
times, but could not get a good connection.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:191)
at
org.apache.geode.redis.internal.executor.pubsub.AbstractPubSubIntegrationTest.ensureOrderingOfPublishedMessages(AbstractPubSubIntegrationTest.java:443)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.apache.geode.NativeRedisTestRule$1.evaluate(NativeRedisTestRule.java:67)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMetho
[jira] [Commented] (GEODE-8787) CI Failure: PubSubNativeRedisAcceptanceTest.ensureOrderingOfPublishedMessages FAILED
[
https://issues.apache.org/jira/browse/GEODE-8787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249335#comment-17249335
]
Geode Integration commented on GEODE-8787:
--
Seen in [AcceptanceTestOpenJDK11
#631|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/631]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0553/test-results/acceptanceTest/1607981512/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0553/test-artifacts/1607981512/acceptancetestfiles-OpenJDK11-1.14.0-build.0553.tgz].
> CI Failure: PubSubNativeRedisAcceptanceTest.ensureOrderingOfPublishedMessages
> FAILED
>
>
> Key: GEODE-8787
> URL: https://issues.apache.org/jira/browse/GEODE-8787
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Eric Shu
>Priority: Major
>
> Test run failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/631
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.RuntimeException: Tried 10
> times, but could not get a good connection.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractPubSubIntegrationTest.ensureOrderingOfPublishedMessages(AbstractPubSubIntegrationTest.java:443)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.NativeRedisTestRule$1.evaluate(NativeRedisTestRule.java:67)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
[jira] [Commented] (GEODE-8665) validate offline-disk-store command is missing information
[
https://issues.apache.org/jira/browse/GEODE-8665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249336#comment-17249336
]
ASF GitHub Bot commented on GEODE-8665:
---
gesterzhou commented on a change in pull request #5801:
URL: https://github.com/apache/geode/pull/5801#discussion_r542832250
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ValidateOfflineDiskStoreDUnitTest.java
##
@@ -0,0 +1,281 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.HTTP_SERVICE_PORT;
+import static org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER;
+import static
org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER_PORT;
+import static
org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER_START;
+import static org.apache.geode.distributed.ConfigurationProperties.LOCATORS;
+import static org.apache.geode.distributed.ConfigurationProperties.LOG_FILE;
+import static
org.apache.geode.distributed.ConfigurationProperties.MAX_WAIT_TIME_RECONNECT;
+import static
org.apache.geode.distributed.ConfigurationProperties.MEMBER_TIMEOUT;
+import static
org.apache.geode.internal.AvailablePortHelper.getRandomAvailableTCPPorts;
+import static org.apache.geode.internal.lang.SystemPropertyHelper.GEODE_PREFIX;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.dunit.Disconnect.disconnectAllFromDS;
+import static org.apache.geode.test.dunit.Invoke.invokeInEveryVM;
+import static org.apache.geode.test.dunit.VM.getVM;
+import static org.apache.geode.test.dunit.VM.getVMId;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.Mockito.mock;
+
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.PrintStream;
+import java.io.Serializable;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.cache.client.ClientRegionShortcut;
+import org.apache.geode.distributed.LocatorLauncher;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.distributed.internal.InternalLocator;
+import org.apache.geode.internal.lang.SystemPropertyHelper;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.dunit.VM;
+import org.apache.geode.test.dunit.rules.DistributedRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import
org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder;
+
+public class ValidateOfflineDiskStoreDUnitTest implements Serializable {
+
+ @Rule
+ public transient GfshCommandRule gfsh = new GfshCommandRule();
+
+ @Rule
+ public SerializableTemporaryFolder temporaryFolder = new
SerializableTemporaryFolder();
+
+ @Rule
+ public DistributedRule distributedRule = new DistributedRule(2);
+
+ private String locatorName;
+
+ private File locatorDir;
+
+ private int locatorPort;
+
+ private int locatorJmxPort;
+
+ private static final LocatorLauncher DUMMY_LOCATOR =
mock(LocatorLauncher.class);
+
+ private static final AtomicReference LOCATOR =
+ new AtomicReference<>(DUMMY_LOCATOR);
+
+ private VM server;
+
+ private String serverName;
+
+ private File serverDir;
+
+ private int serverPort;
+
+ private String locators;
+
+ private static final ServerLauncher DUMMY_SERVER =
mock(ServerLauncher.class);
+
+ private static final AtomicReference SERVER =
+ new AtomicReference<>(DUMMY_SERVER);
+
+ private final int NUM_ENTRIES = 1000;
+
+ private static final String DISK_STORE_NAME = "testDiskStore";
+
+ private static final String REGION_NAME = "testRegion";
+
+ @Before
+ public void setUp() throws Exception {
+VM locator = getVM(0);
+server = getVM(1);
+
+l
[jira] [Created] (GEODE-8788) CI Failure: CqQueryOptimizedExecuteDUnitTest.testWithoutCQs FAILED
Eric Shu created GEODE-8788:
---
Summary: CI Failure:
CqQueryOptimizedExecuteDUnitTest.testWithoutCQs FAILED
Key: GEODE-8788
URL: https://issues.apache.org/jira/browse/GEODE-8788
Project: Geode
Issue Type: Bug
Components: cq
Reporter: Eric Shu
Test run failed:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/694
{noformat}
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm1.log' at line 593
[fatal 2020/12/14 18:19:05.096 GMT
tid=408] Server connection from
[identity(172.17.0.4(254):41004,connection=1; port=55048] : Unexpected
Error on server
org.apache.geode.InternalGemFireError: No cache client proxy on this node for
proxyId identity(172.17.0.4(254):41004,connection=1
at
org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.makePrimary(CacheClientNotifier.java:515)
at
org.apache.geode.internal.cache.tier.sockets.command.MakePrimary.cmdExecute(MakePrimary.java:56)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1214)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:691)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.lang.Thread.run(Thread.java:748)
at org.junit.Assert.fail(Assert.java:89)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:408)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
[jira] [Commented] (GEODE-8788) CI Failure: CqQueryOptimizedExecuteDUnitTest.testWithoutCQs FAILED
[
https://issues.apache.org/jira/browse/GEODE-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249342#comment-17249342
]
Geode Integration commented on GEODE-8788:
--
Seen in [DistributedTestOpenJDK8
#694|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/694]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0552/test-results/distributedTest/1607976239/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0552/test-artifacts/1607976239/distributedtestfiles-OpenJDK8-1.14.0-build.0552.tgz].
> CI Failure: CqQueryOptimizedExecuteDUnitTest.testWithoutCQs FAILED
> --
>
> Key: GEODE-8788
> URL: https://issues.apache.org/jira/browse/GEODE-8788
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Eric Shu
>Priority: Major
>
> Test run failed:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/694
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm1.log' at line 593
> [fatal 2020/12/14 18:19:05.096 GMT
> tid=408] Server connection from
> [identity(172.17.0.4(254):41004,connection=1; port=55048] : Unexpected
> Error on server
> org.apache.geode.InternalGemFireError: No cache client proxy on this node for
> proxyId identity(172.17.0.4(254):41004,connection=1
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.makePrimary(CacheClientNotifier.java:515)
> at
> org.apache.geode.internal.cache.tier.sockets.command.MakePrimary.cmdExecute(MakePrimary.java:56)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1214)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:691)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.lang.Thread.run(Thread.java:748)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:408)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.jun
[jira] [Commented] (GEODE-8665) validate offline-disk-store command is missing information
[
https://issues.apache.org/jira/browse/GEODE-8665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249344#comment-17249344
]
ASF GitHub Bot commented on GEODE-8665:
---
jchen21 commented on a change in pull request #5801:
URL: https://github.com/apache/geode/pull/5801#discussion_r542840591
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/ValidateOfflineDiskStoreDUnitTest.java
##
@@ -0,0 +1,281 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.HTTP_SERVICE_PORT;
+import static org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER;
+import static
org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER_PORT;
+import static
org.apache.geode.distributed.ConfigurationProperties.JMX_MANAGER_START;
+import static org.apache.geode.distributed.ConfigurationProperties.LOCATORS;
+import static org.apache.geode.distributed.ConfigurationProperties.LOG_FILE;
+import static
org.apache.geode.distributed.ConfigurationProperties.MAX_WAIT_TIME_RECONNECT;
+import static
org.apache.geode.distributed.ConfigurationProperties.MEMBER_TIMEOUT;
+import static
org.apache.geode.internal.AvailablePortHelper.getRandomAvailableTCPPorts;
+import static org.apache.geode.internal.lang.SystemPropertyHelper.GEODE_PREFIX;
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.apache.geode.test.dunit.Disconnect.disconnectAllFromDS;
+import static org.apache.geode.test.dunit.Invoke.invokeInEveryVM;
+import static org.apache.geode.test.dunit.VM.getVM;
+import static org.apache.geode.test.dunit.VM.getVMId;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.Mockito.mock;
+
+import java.io.ByteArrayOutputStream;
+import java.io.File;
+import java.io.PrintStream;
+import java.io.Serializable;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.stream.IntStream;
+
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.cache.client.ClientRegionShortcut;
+import org.apache.geode.distributed.LocatorLauncher;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.distributed.internal.InternalLocator;
+import org.apache.geode.internal.lang.SystemPropertyHelper;
+import org.apache.geode.management.internal.cli.util.CommandStringBuilder;
+import org.apache.geode.test.dunit.VM;
+import org.apache.geode.test.dunit.rules.DistributedRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+import
org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder;
+
+public class ValidateOfflineDiskStoreDUnitTest implements Serializable {
+
+ @Rule
+ public transient GfshCommandRule gfsh = new GfshCommandRule();
+
+ @Rule
+ public SerializableTemporaryFolder temporaryFolder = new
SerializableTemporaryFolder();
+
+ @Rule
+ public DistributedRule distributedRule = new DistributedRule(2);
+
+ private String locatorName;
+
+ private File locatorDir;
+
+ private int locatorPort;
+
+ private int locatorJmxPort;
+
+ private static final LocatorLauncher DUMMY_LOCATOR =
mock(LocatorLauncher.class);
+
+ private static final AtomicReference LOCATOR =
+ new AtomicReference<>(DUMMY_LOCATOR);
+
+ private VM server;
+
+ private String serverName;
+
+ private File serverDir;
+
+ private int serverPort;
+
+ private String locators;
+
+ private static final ServerLauncher DUMMY_SERVER =
mock(ServerLauncher.class);
+
+ private static final AtomicReference SERVER =
+ new AtomicReference<>(DUMMY_SERVER);
+
+ private final int NUM_ENTRIES = 1000;
+
+ private static final String DISK_STORE_NAME = "testDiskStore";
+
+ private static final String REGION_NAME = "testRegion";
+
+ @Before
+ public void setUp() throws Exception {
+VM locator = getVM(0);
+server = getVM(1);
+
+loca
[jira] [Assigned] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-8789:
--
Assignee: Donal Evans
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
Donal Evans created GEODE-8789:
--
Summary: Inconsistent logging when using
BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
Key: GEODE-8789
URL: https://issues.apache.org/jira/browse/GEODE-8789
Project: Geode
Issue Type: Improvement
Components: logging
Reporter: Donal Evans
The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
String "regionName" and uses them to construct an exception message. However,
some areas of code that call this method format the "title" String to already
contain the region name, leading to the name being logged twice and potentially
causing confusion. Calls to this method should be changed to not include the
region name in the "title" String.
{code:java}
protected static void writeRegionDestroyedEx(Message msg, String regionName,
String title,
ServerConnection serverConnection) throws IOException {
String reason = serverConnection.getName() + ": Region named " + regionName
+ title;
RegionDestroyedException ex = new RegionDestroyedException(reason,
regionName);
if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
writeChunkedException(msg, ex, serverConnection);
} else {
writeException(msg, ex, false, serverConnection);
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249366#comment-17249366
]
ASF GitHub Bot commented on GEODE-8789:
---
DonalEvans opened a new pull request #5850:
URL: https://github.com/apache/geode/pull/5850
- Do not format the String containing the reason for the exception to
contain the region name
Authored-by: Donal Evans
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
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8789:
--
Labels: pull-request-available (was: )
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249367#comment-17249367 ] ASF GitHub Bot commented on GEODE-8728: --- lgtm-com[bot] commented on pull request #5848: URL: https://github.com/apache/geode/pull/5848#issuecomment-744755646 This pull request **fixes 1 alert** when merging 35dd329633db745e84ab399d31688415caae04af into bda0d3fbf13ebdf37db8d710cf7f4d4b892a1646 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-bc28d2d5de8c69468b1846b9344aaa33fae764f5) **fixed alerts:** * 1 for Dereferenced variable may be null 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[ https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249381#comment-17249381 ] Bill Burcham commented on GEODE-8739: - [~upthewaterspout] wondered: Do we have a plan for how we can safely delete the .dat file with geode-for-k8s to work around the issue without introducing new bugs? Or should we be sticking with our existing 30 second sleep workaround until we implement some new network partition detection logic? [~burcham] answers: We have no plan for deleting that .dat file. We recognize the problem. For now the 30-second sleep is the best workaround. A more fulsome solution to network partition detection is needed. > Split brain when locators exhaust join attempts on non existant servers > --- > > Key: GEODE-8739 > URL: https://issues.apache.org/jira/browse/GEODE-8739 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jason Huynh >Priority: Major > Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip > > > The hypothesis: "if there is a locator view .dat file with several > non-existent servers then then locators will waste all of their join attempts > on the servers instead of finding each other" > Scenario is a test/user attempts to recreate a cluster with existing .dat and > persistent files. The locators are spun in parallel and from the analysis, > it looks like they are able to communicate with each other, but then end up > forming their own ds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8790) Evicted entries sometimes remain in region map
Louis R. Jacome created GEODE-8790: -- Summary: Evicted entries sometimes remain in region map Key: GEODE-8790 URL: https://issues.apache.org/jira/browse/GEODE-8790 Project: Geode Issue Type: Bug Components: eviction Reporter: Louis R. Jacome Sometimes an entry set for eviction will remain in the region map after falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. When testing the LRU capacity of a region, we create many entries beyond the LRU capacity, causing evictions. We sometimes run into a case where two threads compete to remove the same entry. One thread succeeds and removes it from the region map, while the other thread, in removal progress, will create a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8790) Evicted entries sometimes remain in region map
[ https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8790: -- Labels: pull-request-available (was: ) > Evicted entries sometimes remain in region map > -- > > Key: GEODE-8790 > URL: https://issues.apache.org/jira/browse/GEODE-8790 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Louis R. Jacome >Priority: Major > Labels: pull-request-available > > Sometimes an entry set for eviction will remain in the region map after > falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. > When testing the LRU capacity of a region, we create many entries beyond the > LRU capacity, causing evictions. We sometimes run into a case where two > threads compete to remove the same entry. One thread succeeds and removes it > from the region map, while the other thread, in removal progress, will create > a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8790) Evicted entries sometimes remain in region map
[ https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249393#comment-17249393 ] ASF GitHub Bot commented on GEODE-8790: --- luissson closed pull request #5842: URL: https://github.com/apache/geode/pull/5842 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 > Evicted entries sometimes remain in region map > -- > > Key: GEODE-8790 > URL: https://issues.apache.org/jira/browse/GEODE-8790 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Louis R. Jacome >Priority: Major > > Sometimes an entry set for eviction will remain in the region map after > falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. > When testing the LRU capacity of a region, we create many entries beyond the > LRU capacity, causing evictions. We sometimes run into a case where two > threads compete to remove the same entry. One thread succeeds and removes it > from the region map, while the other thread, in removal progress, will create > a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8790) Evicted entries sometimes remain in region map
[ https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249394#comment-17249394 ] ASF GitHub Bot commented on GEODE-8790: --- luissson opened a new pull request #5851: URL: https://github.com/apache/geode/pull/5851 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 > Evicted entries sometimes remain in region map > -- > > Key: GEODE-8790 > URL: https://issues.apache.org/jira/browse/GEODE-8790 > Project: Geode > Issue Type: Bug > Components: eviction >Reporter: Louis R. Jacome >Priority: Major > Labels: pull-request-available > > Sometimes an entry set for eviction will remain in the region map after > falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. > When testing the LRU capacity of a region, we create many entries beyond the > LRU capacity, causing evictions. We sometimes run into a case where two > threads compete to remove the same entry. One thread succeeds and removes it > from the region map, while the other thread, in removal progress, will create > a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8790) Evicted entries sometimes remain in region map
[ https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Louis R. Jacome updated GEODE-8790: --- Affects Version/s: 1.14.0 1.1.0 > Evicted entries sometimes remain in region map > -- > > Key: GEODE-8790 > URL: https://issues.apache.org/jira/browse/GEODE-8790 > Project: Geode > Issue Type: Bug > Components: eviction >Affects Versions: 1.1.0, 1.14.0 >Reporter: Louis R. Jacome >Priority: Major > Labels: pull-request-available > > Sometimes an entry set for eviction will remain in the region map after > falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. > When testing the LRU capacity of a region, we create many entries beyond the > LRU capacity, causing evictions. We sometimes run into a case where two > threads compete to remove the same entry. One thread succeeds and removes it > from the region map, while the other thread, in removal progress, will create > a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8790) Evicted entries sometimes remain in region map
[ https://issues.apache.org/jira/browse/GEODE-8790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Louis R. Jacome reassigned GEODE-8790: -- Assignee: Louis R. Jacome > Evicted entries sometimes remain in region map > -- > > Key: GEODE-8790 > URL: https://issues.apache.org/jira/browse/GEODE-8790 > Project: Geode > Issue Type: Bug > Components: eviction >Affects Versions: 1.1.0, 1.14.0 >Reporter: Louis R. Jacome >Assignee: Louis R. Jacome >Priority: Major > Labels: pull-request-available > > Sometimes an entry set for eviction will remain in the region map after > falling into an unhandled case in RegionMapDestroy.retryRemoveWithTombstone. > When testing the LRU capacity of a region, we create many entries beyond the > LRU capacity, causing evictions. We sometimes run into a case where two > threads compete to remove the same entry. One thread succeeds and removes it > from the region map, while the other thread, in removal progress, will create > a temporary entry in the map that does not get properly removed/handled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8791) CI Failure: Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
Eric Shu created GEODE-8791:
---
Summary: CI Failure:
Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
Key: GEODE-8791
URL: https://issues.apache.org/jira/browse/GEODE-8791
Project: Geode
Issue Type: Bug
Components: http session
Reporter: Eric Shu
Test run is at:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/660
{noformat}
org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a
lambda expression in org.apache.geode.session.tests.CargoTestBase
expected:<"[Bar]"> but was:<"[Foo]"> within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at
org.apache.geode.session.tests.CargoTestBase.attributesCanBeReplaced(CargoTestBase.java:402)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.N
[jira] [Commented] (GEODE-8791) CI Failure: Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
[
https://issues.apache.org/jira/browse/GEODE-8791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249396#comment-17249396
]
Geode Integration commented on GEODE-8791:
--
Seen in [DistributedTestOpenJDK11
#660|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/660]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0553/test-results/distributedTest/1607985084/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0553/test-artifacts/1607985084/distributedtestfiles-OpenJDK11-1.14.0-build.0553.tgz].
> CI Failure: Jetty9CachingClientServerTest.attributesCanBeReplaced FAILED
>
>
> Key: GEODE-8791
> URL: https://issues.apache.org/jira/browse/GEODE-8791
> Project: Geode
> Issue Type: Bug
> Components: http session
>Reporter: Eric Shu
>Priority: Major
>
> Test run is at:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/660
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as
> a lambda expression in org.apache.geode.session.tests.CargoTestBase
> expected:<"[Bar]"> but was:<"[Foo]"> within 5 minutes.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.session.tests.CargoTestBase.attributesCanBeReplaced(CargoTestBase.java:402)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMetho
[jira] [Commented] (GEODE-8601) Replace ACE ExpiryTaskManager impl by boost::asio one
[
https://issues.apache.org/jira/browse/GEODE-8601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249403#comment-17249403
]
ASF GitHub Bot commented on GEODE-8601:
---
mreddington commented on a change in pull request #678:
URL: https://github.com/apache/geode-native/pull/678#discussion_r542925100
##
File path: cppcache/include/geode/CacheStatistics.hpp
##
@@ -97,11 +97,11 @@ class APACHE_GEODE_EXPORT CacheStatistics {
virtual time_point getLastAccessedTime() const;
private:
- virtual void setLastAccessedTime(time_point lat);
- virtual void setLastModifiedTime(time_point lmt);
+ virtual void setLastAccessedTime(const time_point& tp);
Review comment:
A time_point boils down to maybe a `long long`, is there any pressing
reason to pass by reference, and thus cascade a const reference type change to
this interface through all the derived implementations in all client code?
##
File path: cppcache/include/geode/CacheStatistics.hpp
##
@@ -47,9 +47,9 @@ class LocalRegion;
*/
class APACHE_GEODE_EXPORT CacheStatistics {
public:
- typedef std::chrono::system_clock::time_point time_point;
+ using time_point = std::chrono::steady_clock::time_point;
- CacheStatistics() : m_lastAccessTime(0), m_lastModifiedTime(0) {}
+ CacheStatistics() = default;
Review comment:
`default` will produce an inlined definition that will be compiled in
client code for library code. This is just asking for type pruning problems,
which we've seen before. This constructor should instead be moved into the
source file. Default is fine for internal implementation, not for published
headers.
##
File path: cppcache/integration-test/CMakeLists.txt
##
@@ -114,6 +115,7 @@ endif()
target_link_libraries(${TEST}
PRIVATE
ACE::ACE
+ Boost::boost
Review comment:
Same.
##
File path: cppcache/include/geode/CacheStatistics.hpp
##
@@ -97,11 +97,11 @@ class APACHE_GEODE_EXPORT CacheStatistics {
virtual time_point getLastAccessedTime() const;
private:
- virtual void setLastAccessedTime(time_point lat);
- virtual void setLastModifiedTime(time_point lmt);
+ virtual void setLastAccessedTime(const time_point& tp);
+ virtual void setLastModifiedTime(const time_point& tp);
- std::atomic m_lastAccessTime;
- std::atomic m_lastModifiedTime;
+ std::atomic last_accessed_{0};
Review comment:
This change also inlines into client code. Don't get me wrong, the
original constructor was just as wrong, it should have just been moved into the
source file. Save this sort of thing for internal implementation, not published
headers.
##
File path: cppcache/integration-test/CMakeLists.txt
##
@@ -25,6 +25,7 @@ add_library(test-cppcache-utils STATIC
target_link_libraries(test-cppcache-utils
PRIVATE
ACE::ACE
+Boost::boost
Review comment:
Do you need all of Boost? You should be able to include just the
libraries you need, Boost::asio, for example.
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
> Replace ACE ExpiryTaskManager impl by boost::asio one
> -
>
> Key: GEODE-8601
> URL: https://issues.apache.org/jira/browse/GEODE-8601
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WOULD LIKE* to replace ACE implementation of ExpiryTaskManager for a
> boost::asio one
> *SO THAT* all issues related to it disappear, the implementation is more
> simple and move away from ACE as it's the project policy for a while.
> —
> *Additional information*
> Current implementation of ExpiryTaskManager is causing issue GEODE-8535 and
> some other related, not yet reported.
> Also, as I am aware the project is moving away from ACE, so I'd say this is
> the perfect oportunity to replace ExpiryTaskManager implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249405#comment-17249405
]
Geode Integration commented on GEODE-8191:
--
Seen in [DistributedTestOpenJDK11
#661|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/661]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0554/test-results/distributedTest/1607985697/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0554/test-artifacts/1607985697/distributedtestfiles-OpenJDK11-1.14.0-build.0554.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.14.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8778) Change the default value of conserve-sockets to false
[ https://issues.apache.org/jira/browse/GEODE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-8778. Fix Version/s: 1.14.0 Resolution: Fixed > Change the default value of conserve-sockets to false > - > > Key: GEODE-8778 > URL: https://issues.apache.org/jira/browse/GEODE-8778 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > See also the dev list discussion on this subject. > First, from the docs[1], a brief explanation of the purpose of the > conserve-sockets property: > > "The conserve-sockets setting indicates whether application threads share > sockets with other threads or use their own sockets for member communication. > This setting has no effect on communication between a server and its clients, > but it does control the server’s communication with its peers or a gateway > sender’s communication with a gateway receiver." > > The current default value for the conserve-sockets property is true, which > at first glance makes sense, since in an ideal world, existing sockets could > be shared between threads and there would be no need to create and destroy > new sockets for each process, which can be somewhat resource-intensive. > However, in practice, there are several known issues with using the default > setting of true. From the docs[1]: > > "For distributed regions, the put operation, and destroy and invalidate for > regions and entries, can all be optimized with conserve-sockets set to false. > For partitioned regions, setting conserve-sockets to false can improve > general throughput. > Note: When you have transactions operating on EMPTY, NORMAL or PARTITION > regions, make sure that conserve-sockets is set to false to avoid distributed > deadlocks." > > and[2]: > > "WAN deployments increase the messaging demands on a Geode system. To avoid > hangs related to WAN messaging, always set `conserve-sockets=false` for Geode > members that participate in a WAN deployment." > > Given that it is generally accepted as best practice to set conserve-sockets > to false for almost all use cases of Geode beyond the most simple, it would > make sense to also change the default value to false, to prevent people > having to encounter a problem, search for the solution, then change the > setting to what is almost always the "correct" value. > > [1] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html|http://example.com/] > [2] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8778) Change the default value of conserve-sockets to false
[ https://issues.apache.org/jira/browse/GEODE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249406#comment-17249406 ] ASF GitHub Bot commented on GEODE-8778: --- DonalEvans merged pull request #5832: URL: https://github.com/apache/geode/pull/5832 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 > Change the default value of conserve-sockets to false > - > > Key: GEODE-8778 > URL: https://issues.apache.org/jira/browse/GEODE-8778 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > Labels: pull-request-available > > See also the dev list discussion on this subject. > First, from the docs[1], a brief explanation of the purpose of the > conserve-sockets property: > > "The conserve-sockets setting indicates whether application threads share > sockets with other threads or use their own sockets for member communication. > This setting has no effect on communication between a server and its clients, > but it does control the server’s communication with its peers or a gateway > sender’s communication with a gateway receiver." > > The current default value for the conserve-sockets property is true, which > at first glance makes sense, since in an ideal world, existing sockets could > be shared between threads and there would be no need to create and destroy > new sockets for each process, which can be somewhat resource-intensive. > However, in practice, there are several known issues with using the default > setting of true. From the docs[1]: > > "For distributed regions, the put operation, and destroy and invalidate for > regions and entries, can all be optimized with conserve-sockets set to false. > For partitioned regions, setting conserve-sockets to false can improve > general throughput. > Note: When you have transactions operating on EMPTY, NORMAL or PARTITION > regions, make sure that conserve-sockets is set to false to avoid distributed > deadlocks." > > and[2]: > > "WAN deployments increase the messaging demands on a Geode system. To avoid > hangs related to WAN messaging, always set `conserve-sockets=false` for Geode > members that participate in a WAN deployment." > > Given that it is generally accepted as best practice to set conserve-sockets > to false for almost all use cases of Geode beyond the most simple, it would > make sense to also change the default value to false, to prevent people > having to encounter a problem, search for the solution, then change the > setting to what is almost always the "correct" value. > > [1] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html|http://example.com/] > [2] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8778) Change the default value of conserve-sockets to false
[ https://issues.apache.org/jira/browse/GEODE-8778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249407#comment-17249407 ] ASF subversion and git services commented on GEODE-8778: Commit ee835e3245e2aa05aa31846e57ee6f771cc76f33 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee835e3 ] GEODE-8778: Change conserve-sockets default value to false (#5832) - Update certain tests to explicitly set conserve-sockets=true to allow them to pass - Update docs to reflect new default - Add ignored exception to test, do not explicitly set conserve-sockets - Add comment to explain use of conserve-sockets=true in test Authored-by: Donal Evans > Change the default value of conserve-sockets to false > - > > Key: GEODE-8778 > URL: https://issues.apache.org/jira/browse/GEODE-8778 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.14.0 >Reporter: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > See also the dev list discussion on this subject. > First, from the docs[1], a brief explanation of the purpose of the > conserve-sockets property: > > "The conserve-sockets setting indicates whether application threads share > sockets with other threads or use their own sockets for member communication. > This setting has no effect on communication between a server and its clients, > but it does control the server’s communication with its peers or a gateway > sender’s communication with a gateway receiver." > > The current default value for the conserve-sockets property is true, which > at first glance makes sense, since in an ideal world, existing sockets could > be shared between threads and there would be no need to create and destroy > new sockets for each process, which can be somewhat resource-intensive. > However, in practice, there are several known issues with using the default > setting of true. From the docs[1]: > > "For distributed regions, the put operation, and destroy and invalidate for > regions and entries, can all be optimized with conserve-sockets set to false. > For partitioned regions, setting conserve-sockets to false can improve > general throughput. > Note: When you have transactions operating on EMPTY, NORMAL or PARTITION > regions, make sure that conserve-sockets is set to false to avoid distributed > deadlocks." > > and[2]: > > "WAN deployments increase the messaging demands on a Geode system. To avoid > hangs related to WAN messaging, always set `conserve-sockets=false` for Geode > members that participate in a WAN deployment." > > Given that it is generally accepted as best practice to set conserve-sockets > to false for almost all use cases of Geode beyond the most simple, it would > make sense to also change the default value to false, to prevent people > having to encounter a problem, search for the solution, then change the > setting to what is almost always the "correct" value. > > [1] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/performance_controls_controlling_socket_use.html|http://example.com/] > [2] > [https://geode.apache.org/docs/guide/113/managing/monitor_tune/sockets_and_gateways.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8792) Support Universal builds on macOS
Jacob Barrett created GEODE-8792: Summary: Support Universal builds on macOS Key: GEODE-8792 URL: https://issues.apache.org/jira/browse/GEODE-8792 Project: Geode Issue Type: Improvement Components: native client Reporter: Jacob Barrett Support Universal builds (x86_64 and arm64) on recent macOS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8763) Benchmark CI only runs tests 4 times
[ https://issues.apache.org/jira/browse/GEODE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8763: Fix Version/s: 1.14.0 > Benchmark CI only runs tests 4 times > > > Key: GEODE-8763 > URL: https://issues.apache.org/jira/browse/GEODE-8763 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The benchmark has a retry mechanism that is supposed to run all tests, then > rerun any failed tests. If tests are still failing then it should retry those > tests, for a total of 5 test runs (including the first run of all the tests). > Currently it only runs the tests a total of 4 times. > Increase the number of runs to 5 to increase the tolerance for variance in > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8763) Benchmark CI only runs tests 4 times
[ https://issues.apache.org/jira/browse/GEODE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8763. - Resolution: Fixed > Benchmark CI only runs tests 4 times > > > Key: GEODE-8763 > URL: https://issues.apache.org/jira/browse/GEODE-8763 > Project: Geode > Issue Type: Bug > Components: benchmarks, ci >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > > The benchmark has a retry mechanism that is supposed to run all tests, then > rerun any failed tests. If tests are still failing then it should retry those > tests, for a total of 5 test runs (including the first run of all the tests). > Currently it only runs the tests a total of 4 times. > Increase the number of runs to 5 to increase the tolerance for variance in > tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8789.
Fix Version/s: 1.14.0
Resolution: Fixed
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249423#comment-17249423
]
ASF GitHub Bot commented on GEODE-8789:
---
DonalEvans merged pull request #5850:
URL: https://github.com/apache/geode/pull/5850
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
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8789:
---
Affects Version/s: 1.14.0
1.12.0
1.13.1
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8789) Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to region name being repeated.
[
https://issues.apache.org/jira/browse/GEODE-8789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249424#comment-17249424
]
ASF subversion and git services commented on GEODE-8789:
Commit 1da2e6558d5ea57c25762e25689c2bede1ca3ed2 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1da2e65 ]
GEODE-8789: Prevent region name from being incorrectly logged twice (#5850)
- The String containing the reason for the exception should
not contain the region name
Authored-by: Donal Evans
> Inconsistent logging when using BaseCommand.writeRegionDestroyedEx() leads to
> region name being repeated.
> -
>
> Key: GEODE-8789
> URL: https://issues.apache.org/jira/browse/GEODE-8789
> Project: Geode
> Issue Type: Improvement
> Components: logging
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> The method BaseCommand.writeRegionDestroyedEx() takes a String "title" and
> String "regionName" and uses them to construct an exception message. However,
> some areas of code that call this method format the "title" String to already
> contain the region name, leading to the name being logged twice and
> potentially causing confusion. Calls to this method should be changed to not
> include the region name in the "title" String.
> {code:java}
> protected static void writeRegionDestroyedEx(Message msg, String regionName,
> String title,
> ServerConnection serverConnection) throws IOException {
> String reason = serverConnection.getName() + ": Region named " +
> regionName + title;
> RegionDestroyedException ex = new RegionDestroyedException(reason,
> regionName);
> if (serverConnection.getTransientFlag(REQUIRES_CHUNKED_RESPONSE)) {
> writeChunkedException(msg, ex, serverConnection);
> } else {
> writeException(msg, ex, false, serverConnection);
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7802) User Guide - add disclaimer that OQL queries are not pre-validated for nonexistent attributes
[ https://issues.apache.org/jira/browse/GEODE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249427#comment-17249427 ] ASF GitHub Bot commented on GEODE-7802: --- davebarnes97 commented on a change in pull request #5844: URL: https://github.com/apache/geode/pull/5844#discussion_r542973121 ## File path: geode-docs/developing/querying_basics/restrictions_and_unsupported_features.html.md.erb ## @@ -30,6 +30,6 @@ At a high level, <%=vars.product_name%> does not support the following querying - You cannot create an index on fields using Set/List types (Collection types) that are not comparable. The OQL index implementation expects fields to be Comparable. To workaround this, you can create a custom Collection type that implements Comparable. - ORDER BY is only supported with DISTINCT queries. - +- OQL queries aren't pre-validated for references to nonexistent methods and attributes. Review comment: I will propose a rewrite tomorrow that incorporates @agingade's verbiage. 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 - add disclaimer that OQL queries are not pre-validated for > nonexistent attributes > - > > Key: GEODE-7802 > URL: https://issues.apache.org/jira/browse/GEODE-7802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member @deepak khopade requests that we add a disclaimer to the > user guide stating that OQL queries are not pre-screened for references to > nonexistent attributes. The assertion is that users who have experience with > other query models may expect Geode to apply such validation. In the Geode > model, attributes and methods are resolved at runtime during query execution > - the server does not know what's actually stored in a region until the query > is executed. > The disclaimer could be added in one of two places: > Query Language Restrictions and Unsupported Features > ([https://geode.apache.org/docs/guide/111/developing/querying_basics/restrictions_and_unsupported_features.html]) > or > Querying FAQ and Examples > ([https://geode.apache.org/docs/guide/111/getting_started/querying_quick_reference.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7802) User Guide - add disclaimer that OQL queries are not pre-validated for nonexistent attributes
[ https://issues.apache.org/jira/browse/GEODE-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249426#comment-17249426 ] ASF GitHub Bot commented on GEODE-7802: --- davebarnes97 commented on a change in pull request #5844: URL: https://github.com/apache/geode/pull/5844#discussion_r542973121 ## File path: geode-docs/developing/querying_basics/restrictions_and_unsupported_features.html.md.erb ## @@ -30,6 +30,6 @@ At a high level, <%=vars.product_name%> does not support the following querying - You cannot create an index on fields using Set/List types (Collection types) that are not comparable. The OQL index implementation expects fields to be Comparable. To workaround this, you can create a custom Collection type that implements Comparable. - ORDER BY is only supported with DISTINCT queries. - +- OQL queries aren't pre-validated for references to nonexistent methods and attributes. Review comment: I will propose a rewrite tomorrow that uses @agingade's verbiage. 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 - add disclaimer that OQL queries are not pre-validated for > nonexistent attributes > - > > Key: GEODE-7802 > URL: https://issues.apache.org/jira/browse/GEODE-7802 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member @deepak khopade requests that we add a disclaimer to the > user guide stating that OQL queries are not pre-screened for references to > nonexistent attributes. The assertion is that users who have experience with > other query models may expect Geode to apply such validation. In the Geode > model, attributes and methods are resolved at runtime during query execution > - the server does not know what's actually stored in a region until the query > is executed. > The disclaimer could be added in one of two places: > Query Language Restrictions and Unsupported Features > ([https://geode.apache.org/docs/guide/111/developing/querying_basics/restrictions_and_unsupported_features.html]) > or > Querying FAQ and Examples > ([https://geode.apache.org/docs/guide/111/getting_started/querying_quick_reference.html]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8667) Duplicate online Oplog compaction after offline Oplog compaction
[ https://issues.apache.org/jira/browse/GEODE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249430#comment-17249430 ] ASF GitHub Bot commented on GEODE-8667: --- jchen21 commented on pull request #5689: URL: https://github.com/apache/geode/pull/5689#issuecomment-744970105 @dschneider-pivotal So far, I still consider the current fix is the best option we can have. We need a convenient and reliable way to tell that the Oplog is offline compacted. The persisted `0` value of `totalCount` in krf serves the purpose. And during persistence recovery, if `totalCount` is `0`, then it is updated with the value of `totalLiveCount`, which is the most accurate value of the number of live entries in the Oplog. I have been thinking about whether we should use the local variable `krfEntryCount`, instead of `totalLiveCount`. At the end of `readKrf()`, the value of `totalLiveCount` and `krfEntryCount` are the same. Because at the beginning of `readKrf()`, `totalLiveCount` and `krfEntryCount` are both 0. And in the `while` loop inside `readKrf()`, both variables are incremented together: `totalLiveCount` is incremented here: https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java#L1765 `krfEntryCount` is incremented here: https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java#L1768 I'd prefer using `totalLiveCount` instead of `krfEntryCount` which is a local variable. 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 > Duplicate online Oplog compaction after offline Oplog compaction > > > Key: GEODE-8667 > URL: https://issues.apache.org/jira/browse/GEODE-8667 > Project: Geode > Issue Type: Bug >Reporter: Jianxia Chen >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Use `compact offline-disk-store` command to compact the Oplogs offline. > Then restart the servers. > The logs show OplogCompactor thread is compacting Oplogs again when > restarting the servers, even though the Oplogs were just compacted offline. > For example: > ``` > [info 2020/10/27 16:32:22.534 PDT tid=0x35] Recovered > values for disk store DEFAULT with unique id > 76393d3c-dd10-4b89-b655-821d37631774 > [info 2020/10/27 16:32:22.535 PDT > tid=0x35] OplogCompactor for DEFAULT compaction oplog id(s): oplog#2 > [info 2020/10/27 16:32:22.537 PDT > tid=0x35] compaction did 2 creates and updates in 2 ms > [info 2020/10/27 16:32:22.537 PDT tid=0x36] Deleted > oplog#2 crf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 krf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 drf for disk store DEFAULT. > ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8728) Configure Gradle to run parallel tests in isolation without Docker [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249432#comment-17249432 ] ASF GitHub Bot commented on GEODE-8728: --- lgtm-com[bot] commented on pull request #5848: URL: https://github.com/apache/geode/pull/5848#issuecomment-744979874 This pull request **fixes 1 alert** when merging 997caf3ed02d99c1ec3f480ffe13d80510edb1ab into 1da2e6558d5ea57c25762e25689c2bede1ca3ed2 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-1b9ff133a6705b16989cc3b10fd909e602e3637e) **fixed alerts:** * 1 for Dereferenced variable may be null 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 > Configure Gradle to run parallel tests in isolation without Docker [PERMANENT] > -- > > Key: GEODE-8728 > URL: https://issues.apache.org/jira/browse/GEODE-8728 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > For tests to behave well when run in parallel, each must refrain from using > ports and test files that are in use by other tests. > Geode's Gradle build isolates concurrently executing tests by running each > test class in a Docker container. To do this, the build applies an open > source "Gradle Dockerized Test" plugin that is obsolete and appears to be > unmaintained. > This ticket removes the obsolete plugin and replaces it with a small amount > of custom Gradle code and a few minor changes to Geode: > - Configure Gradle to assign each concurrently executing test JVM a unique > working directory and a distinct range of ports. > - Change Geode's "available port" feature to allocate ports only from the > ranges assigned by Gradle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249433#comment-17249433 ] ASF GitHub Bot commented on GEODE-8779: --- pivotal-eshu merged pull request #5836: URL: https://github.com/apache/geode/pull/5836 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 > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249434#comment-17249434 ] ASF subversion and git services commented on GEODE-8779: Commit f53fa752e6d322d6fd24237212a3b958a5b882b8 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f53fa75 ] GEODE-8779: Register interest only when local cache is enabled. (#5836) > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8779) There is no need in session management to send events back to clients if local cache is not enabled
[ https://issues.apache.org/jira/browse/GEODE-8779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-8779. - Fix Version/s: 1.14.0 Resolution: Fixed > There is no need in session management to send events back to clients if > local cache is not enabled > --- > > Key: GEODE-8779 > URL: https://issues.apache.org/jira/browse/GEODE-8779 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The original case to send events back to empty proxy client is no longer > needed. Hence it should be removed to avoid unnecessary message sending. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8775) Add Gfsh execute function support to new C++ test framework
[ https://issues.apache.org/jira/browse/GEODE-8775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17249498#comment-17249498 ] ASF GitHub Bot commented on GEODE-8775: --- mmartell commented on pull request #708: URL: https://github.com/apache/geode-native/pull/708#issuecomment-745069873 Good questions moleske. Yes, I have a new ClassAsKey test (which depends on this new gfsh functionality) for C++ ready to submit as soon as this PR gets merged. I chose to keep this PR separate since it really is just a test framework enhancement. 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 Gfsh execute function support to new C++ test framework > --- > > Key: GEODE-8775 > URL: https://issues.apache.org/jira/browse/GEODE-8775 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > > In the course of adding a new C++ test for using a class as a key I > discovered that the new C++ test framework didn't support the gfsh execute > function command. > > Note: This functionality already exists in the new .NET test framework. This > ticket is to add it to the new C++ framework -- This message was sent by Atlassian Jira (v8.3.4#803005)
