[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241374#comment-17241374 ] ASF GitHub Bot commented on GEODE-8738: --- albertogpz commented on a change in pull request #5766: URL: https://github.com/apache/geode/pull/5766#discussion_r533197364 ## File path: geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb ## @@ -387,3 +387,51 @@ boglesbymac(ny-3:88715):36808 | 5371 | 5 |["boglesbymac(ln-1:8865 boglesbymac(ny-4:88724):52993 | 5247 | 6 |["boglesbymac(ln-1:88651):48277","boglesbymac(ln-4:88681):42784","boglesbymac(ln-2:88662):12796","boglesbymac(ln-3:88672):43675"] ``` +### Configuring just one IP address and port to access all gateway receivers in a site + +There could be WAN deployments in which we do not want to expose the IP address and port of every gateway receiver to the other site but instead expose just one IP address and port for all gateway receivers. This way, the internal topology of the site is hidden to the other site. This case is quite common in cloud deployments, in which a reverse proxy/load balancer distributes incoming requests to the site (in our case, replication requests) among the available servers (in our case, gateway receivers). + +<%=vars.product_name%> supports this configuration by means of a particular use of the hostname-for-senders, start-port and end-port parameters of the gateway receiver. + +In order to configure a WAN deployment that hides the gateway receivers behind the same IP address and port, all the gateway receivers must have the same value for the hostname-for-senders parameter (the hostname or IP address to be used by clients to access them) and the same value in the start-port and end-port parameters (the port to be used by clients to access them). + +As an example, a deployment in which all gateway receivers of a site are accessed via the "gateway1.mycompany.com" hostname and port "1971", every gateway receiver in that site must be configured as follows: + +``` pre +gfsh> create gateway-receiver --hostname-for-senders="gateway1.mycompany.com" --start-port=1971 --end-port=1971 +``` + +The following output shows how the receiver side would look like after this configuration if 4 gateway recievers were configured: Review comment: Good catch, Alberto! Thanks. 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 > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8749) Create new geode example about cache and region snapshot
Ashish Choudhary created GEODE-8749: --- Summary: Create new geode example about cache and region snapshot Key: GEODE-8749 URL: https://issues.apache.org/jira/browse/GEODE-8749 Project: Geode Issue Type: New Feature Components: examples Reporter: Ashish Choudhary Create new geode example about cache and region snapshot -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8750) Size tracking for LRUEntriesMap is not accurate
Mario Salazar de Torres created GEODE-8750: -- Summary: Size tracking for LRUEntriesMap is not accurate Key: GEODE-8750 URL: https://issues.apache.org/jira/browse/GEODE-8750 Project: Geode Issue Type: Bug Components: native client Affects Versions: 1.13.0, 1.12.0 Reporter: Mario Salazar de Torres LRUEntriesMap uses only key and value object size to keep track of the heap memory consumed by the entries. Thing is there are some more pieces of memory involved in storing this entries and they are not being taken into account. Those are: * Hash table internals memory (buckets, nodes...). * Smart pointer internals (control block...). * Any other memory used to store information about the LRUMap. The purpose of this issue is to set the line on when it is reasonable to stop measuring the heap memory consumed, and after that put in place a proper implementation to track used heap memory within what's feasible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8751) Create new geode example about compression
Ashish Choudhary created GEODE-8751: --- Summary: Create new geode example about compression Key: GEODE-8751 URL: https://issues.apache.org/jira/browse/GEODE-8751 Project: Geode Issue Type: New Feature Components: examples Reporter: Ashish Choudhary Create new geode example about compression -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8751) Create new geode example about compression
[ https://issues.apache.org/jira/browse/GEODE-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Choudhary reassigned GEODE-8751: --- Assignee: Ashish Choudhary > Create new geode example about compression > -- > > Key: GEODE-8751 > URL: https://issues.apache.org/jira/browse/GEODE-8751 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > > Create new geode example about compression -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241585#comment-17241585
]
ASF GitHub Bot commented on GEODE-8202:
---
alb3rtobr commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r533469342
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -348,11 +349,56 @@ public void destroyConnection() {
}
}
+ Connection retryInitializeConnection(Connection con) {
+final boolean isDebugEnabled = logger.isDebugEnabled();
+ServerLocation server = this.sender.getServerLocation();
+String connectedServerId = con.getEndpoint().getMemberId().getUniqueId();
+String expectedServerId = this.processor.getExpectedReceiverUniqueId();
+boolean connectedToExpectedReceiver =
connectedServerId.equals(expectedServerId);
+if (expectedServerId.equals("")) {
+ if (isDebugEnabled) {
+logger.debug("First dispatcher connected to endpoint " +
connectedServerId);
+ }
+ this.processor.setExpectedReceiverUniqueId(connectedServerId);
+ connectedToExpectedReceiver = true;
+}
+int attempt = 0;
+final int maxAttempts = 5;
Review comment:
If several receivers are sharing the same ip and port, the connection
will be assigned randomly by an external proxy or load balancer. Its true that
using this fix value is not the best option... If for example we have 5
receivers, we could spend all the connection retries without reaching the
desired receiver.
Maybe I could increment the value of `maxAttempt` when a connection to a
wrong receiver is obtained and its the first time we reach that wrong receiver.
This will cause that `maxAttempt` value is dependent on the number of receivers.
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
> New option for serial gw sender threads start when receivers share ip and port
> --
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-5782.
---
Fix Version/s: 1.14.0
Resolution: Fixed
Please reopen if it happens again
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.14.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241615#comment-17241615
]
ASF GitHub Bot commented on GEODE-5782:
---
jdeppe-pivotal merged pull request #5648:
URL: https://github.com/apache/geode/pull/5648
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
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-5782:
--
Labels: (was: pull-request-available)
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241617#comment-17241617
]
ASF subversion and git services commented on GEODE-5782:
Commit 70470897e2aa3bcd6f92e12231888f357d2b708c in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7047089 ]
GEODE-5782: Try to improve memory reporting stats for Windows (#5648)
- In order to have a better chance to converge on values, reduce the
sample rate and await for at most 5 sample periods before failing.
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241657#comment-17241657
]
ASF GitHub Bot commented on GEODE-7489:
---
bschuchardt merged pull request #5783:
URL: https://github.com/apache/geode/pull/5783
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
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241658#comment-17241658
]
ASF subversion and git services commented on GEODE-7489:
Commit 1bca72803df43184457c03fdde012139f99ea285 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1bca728 ]
GEODE-7489: DistributionArchUnitTest is running out of memory for some users
(#5783)
CoreOnlyUsesMembershipAPIArchUnitTest already restricts use of the
membership API to certain classes and does so in a way that avoids using
too much memory. Consequently we're removing this test that needs
upwards of 1.5gb of heap since it performs nearly the same test but
for a specific class in the API package instead of the whole package.
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt closed GEODE-7489.
-
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: no-release-note, pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7489.
---
Resolution: Resolved (was: Fixed)
resolved by removing this largely redundant test
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-7489:
--
Labels: no-release-note pull-request-available (was:
pull-request-available)
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: no-release-note, pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
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=17241718#comment-17241718
]
ASF GitHub Bot commented on GEODE-8667:
---
gesterzhou commented on a change in pull request #5689:
URL: https://github.com/apache/geode/pull/5689#discussion_r533588541
##
File path: geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java
##
@@ -5789,9 +5789,8 @@ boolean needsCompaction() {
if (((rv / (double) rvHWMtmp) * 100) <= parent.getCompactionThreshold())
{
return true;
}
-} else {
Review comment:
The new fix is good.
Should use "} else if (hasNoLiveValues()) {" instead.
And it's better to add a few comments 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
> 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-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241720#comment-17241720 ] ASF GitHub Bot commented on GEODE-8745: --- nabarunnag merged pull request #5770: URL: https://github.com/apache/geode/pull/5770 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 > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241723#comment-17241723 ] ASF subversion and git services commented on GEODE-8745: Commit 888e4734ac532a4465e2818010c7983ee57009a2 in geode's branch refs/heads/develop from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=888e473 ] GEODE-8745: Closing the queue region when senders are stopped (#5770) * cleanQueues are applicable only while using persistence * when we are closing the region, the disk files are not deleted. * hence the values will still be maintained on restart. * Advantage will be that we are creating the queue region and its cache listener together * previously the region was not closed and cache listener was attached using mutators. * this caused secondary events to be missed before the cache listener is activated > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241724#comment-17241724 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans merged pull request #5781: URL: https://github.com/apache/geode/pull/5781 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 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241725#comment-17241725 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans merged pull request #5782: URL: https://github.com/apache/geode/pull/5782 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 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241729#comment-17241729 ] ASF subversion and git services commented on GEODE-8734: Commit 787b244566070050603b38e2633d3b7272e2221d in geode's branch refs/heads/support/1.12 from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=787b244 ] GEODE-8734: Parse netstat file to ensure correct stats are retrieved (#5781) Authored-by: Donal Evans (cherry picked from commit 790af0d473bbe2444fb896d8b77c64116c463774) > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241730#comment-17241730 ] ASF subversion and git services commented on GEODE-8734: Commit 66d33fe3593d7b4a59da06045fd0d20636883579 in geode's branch refs/heads/support/1.13 from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=66d33fe ] GEODE-8734: Parse netstat file to ensure correct stats are retrieved (#5782) Authored-by: Donal Evans (cherry picked from commit 790af0d473bbe2444fb896d8b77c64116c463774) > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8734: Fix Version/s: 1.13.2 1.14.0 1.12.1 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.2 > > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8734. - Resolution: Fixed > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.2 > > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241737#comment-17241737
]
Bill Burcham commented on GEODE-8704:
-
This bug is present in the support/1.12 branch. Here's a test failure:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK11/builds/129
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
[jira] [Comment Edited] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241737#comment-17241737
]
Bill Burcham edited comment on GEODE-8704 at 12/1/20, 6:07 PM:
---
This bug is present in the support/1.12 branch. Here's a test failure:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK11/builds/129
This fix needs to be back-ported to support/1.13 and support/1.12
was (Author: bburcham):
This bug is present in the support/1.12 branch. Here's a test failure:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK11/builds/129
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions a
[jira] [Updated] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8704:
Affects Version/s: 1.12.0
1.13.1
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.12.0, 1.14.0, 1.13.1
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMsCaused by:
> org.awaitility.core.ConditionTimeoutException: Condition with alias
> 'for region to be empty' didn't complete within 5 minutes because assertion
> cond
[jira] [Commented] (GEODE-8266) StatForNotQueuedConflated not incremented in time
[
https://issues.apache.org/jira/browse/GEODE-8266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241775#comment-17241775
]
Geode Integration commented on GEODE-8266:
--
Seen in [WindowsUnitTestOpenJDK11
#582|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/582]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-results/test/1606754956/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-artifacts/1606754956/windows-unittestfiles-OpenJDK11-1.14.0-build.0519.tgz].
> StatForNotQueuedConflated not incremented in time
> -
>
> Key: GEODE-8266
> URL: https://issues.apache.org/jira/browse/GEODE-8266
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bill Burcham
>Priority: Major
>
> Failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/259#A
> {code}
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest
> >
> whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented
> FAILED
> java.lang.AssertionError: expected:<1> but was:<0>
> 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.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueueJUnitTest.whenNullPeekedEventFromBucketRegionQueueTheStatForNotQueuedConflatedShouldBeIncremented(ParallelGatewaySenderQueueJUnitTest.java:146)
> {code}
> It appears we are waiting 100ms for the statistic to be incremented. Perhaps
> we need to wait longer. Or maybe there is product bug here?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8751) Create new geode example about compression
[ https://issues.apache.org/jira/browse/GEODE-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241777#comment-17241777 ] ASF GitHub Bot commented on GEODE-8751: --- yrashish opened a new pull request #106: URL: https://github.com/apache/geode-examples/pull/106 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 > Create new geode example about compression > -- > > Key: GEODE-8751 > URL: https://issues.apache.org/jira/browse/GEODE-8751 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > > Create new geode example about compression -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8751) Create new geode example about compression
[ https://issues.apache.org/jira/browse/GEODE-8751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8751: -- Labels: pull-request-available (was: ) > Create new geode example about compression > -- > > Key: GEODE-8751 > URL: https://issues.apache.org/jira/browse/GEODE-8751 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > Labels: pull-request-available > > Create new geode example about compression -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8748) Altering expiry time on proxy region causes NPE
[
https://issues.apache.org/jira/browse/GEODE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241781#comment-17241781
]
ASF GitHub Bot commented on GEODE-8748:
---
DonalEvans commented on a change in pull request #5790:
URL: https://github.com/apache/geode/pull/5790#discussion_r533641921
##
File path:
geode-gfsh/src/distributedTest/java/org/apache/geode/management/internal/cli/commands/AlterTimeToLiveExpirationOnProxyRegionDUnitTest.java
##
@@ -0,0 +1,74 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import junitparams.JUnitParamsRunner;
+import junitparams.Parameters;
+import junitparams.naming.TestCaseName;
+import org.junit.Rule;
+import org.junit.Test;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.junit.categories.EvictionTest;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+@Category({EvictionTest.class})
+@RunWith(JUnitParamsRunner.class)
+public class AlterTimeToLiveExpirationOnProxyRegionDUnitTest {
+ @Rule
+ public ClusterStartupRule clusterStartupRule = new ClusterStartupRule();
+ @Rule
+ public GfshCommandRule gfsh = new GfshCommandRule();
+
+ public Object[] getRegionTypePairs() {
+return new Object[] {
+new Object[] {"REPLICATE", "REPLICATE_PROXY"},
+new Object[] {"PARTITION", "PARTITION_PROXY"},
+new Object[] {"PARTITION_REDUNDANT", "PARTITION_PROXY_REDUNDANT"}
+};
+ }
+
+ @Test
+ @Parameters(method = "getRegionTypePairs")
+ @TestCaseName("[{index}] {method} Non Proxy Region Type:{0}; Proxy Region
Type:{1}")
+ public void
whenExpirationIsSetUsingAlterOnProxyRegionThenItShouldNotThrowException(
+ String nonProxyRegionType, String proxyRegionType) throws Exception {
+MemberVM locator = clusterStartupRule.startLocatorVM(0);
+MemberVM server1 = clusterStartupRule.startServerVM(1, "non-proxy",
locator.getPort());
+MemberVM server2 = clusterStartupRule.startServerVM(2, "proxy",
locator.getPort());
Review comment:
These variables are assigned but never used.
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
> Altering expiry time on proxy region causes NPE
> ---
>
> Key: GEODE-8748
> URL: https://issues.apache.org/jira/browse/GEODE-8748
> Project: Geode
> Issue Type: Task
> Components: expiration
>Reporter: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> When we execute
> "create region --name=region --type=PARTITION_PROXY --group=proxy"
> "alter region --name=region --entry-time-to-live-expiration=1000
> --entry-time-to-live-expiration-action=destroy --group=proxy"
>
> This results in an NPE. Also if there is a mixture of proxy and non-proxy
> versions of the same region and we could alter some of the non-proxy but the
> proxy region failed on alter commands, then restarts will start encountering
> problems.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-7682. -- Fix Version/s: 1.14.0 Resolution: Fixed > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.14.0 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7682) Create the java API to clear a PartitionedRegion
[ https://issues.apache.org/jira/browse/GEODE-7682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-7682: Assignee: Xiaojian Zhou > Create the java API to clear a PartitionedRegion > > > Key: GEODE-7682 > URL: https://issues.apache.org/jira/browse/GEODE-7682 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 7h 50m > Remaining Estimate: 0h > > This task will just include creating the API which calls the internal > commands to clear the region and send messages to the members hosting the > Partitioned region. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
Dale Emery created GEODE-8752:
-
Summary:
PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
test uses wrong address to revoke
Key: GEODE-8752
URL: https://issues.apache.org/jira/browse/GEODE-8752
Project: Geode
Issue Type: Test
Components: tests
Affects Versions: 1.14.0
Reporter: Dale Emery
PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
test uses the wrong address to revoke persistent members.
The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
address to revoke, but in some circumstances that can return an in appropriate
address.
GEODE-7029 changed the test to use a different mechanism to find the address to
revoke: Walk through all available addresses on all available interfaces to
find a non-loopback IPv4 address. But in some circumstances that can return an
address other than the one used in the to-be-revoked member's ID, and the test
fails.
Both of these methods of getting the revoke address rest on unwarranted
assumptions. The test should instead query the member to discover the address
used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8752:
--
Labels: GeodeOperationAPI (was: )
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-7684: Assignee: Xiaojian Zhou > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241787#comment-17241787 ] ASF GitHub Bot commented on GEODE-8738: --- davebarnes97 merged pull request #5766: URL: https://github.com/apache/geode/pull/5766 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 > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-8752:
-
Assignee: Dale Emery
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7684) Implement the Bucket region clear messages and handling
[ https://issues.apache.org/jira/browse/GEODE-7684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-7684. -- Fix Version/s: 1.14.0 Resolution: Fixed > Implement the Bucket region clear messages and handling > --- > > Key: GEODE-7684 > URL: https://issues.apache.org/jira/browse/GEODE-7684 > Project: Geode > Issue Type: New Feature > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.14.0 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Implement the bucket region clear message, and the handling of the message. > Upon receiving this message the bucket region must be cleared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241789#comment-17241789 ] ASF subversion and git services commented on GEODE-8738: Commit c992f5155193f6339edb6493553aae072581d526 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c992f51 ] GEODE-8738: Updated documentation about WAN deployments with sites wi… (#5766) * GEODE-8738: Updated documentation about WAN deployments with sites with the same IP address and port for all gateway receivers, updated with review comments, fixed typo found in review > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7844) Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code
[ https://issues.apache.org/jira/browse/GEODE-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-7844: Assignee: Xiaojian Zhou > Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code > > > Key: GEODE-7844 > URL: https://issues.apache.org/jira/browse/GEODE-7844 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > In PartitionedRegion class, there're 2 sendMsgByBucket() methods, one for > PutAll, another is for RemoveAll. We are adding the 3rd one for Clear. > Their logic are duplicated in most part. Need to refactor the 3 methods to > avoid duplicate code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241790#comment-17241790 ] ASF subversion and git services commented on GEODE-8738: Commit c992f5155193f6339edb6493553aae072581d526 in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c992f51 ] GEODE-8738: Updated documentation about WAN deployments with sites wi… (#5766) * GEODE-8738: Updated documentation about WAN deployments with sites with the same IP address and port for all gateway receivers, updated with review comments, fixed typo found in review > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7858) PR.clear notify client should let the queue holder member to notify
[ https://issues.apache.org/jira/browse/GEODE-7858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241799#comment-17241799 ] ASF subversion and git services commented on GEODE-7858: Commit 54ca6f445affeebc6ae3e68f0c30dce8947aef27 in geode's branch refs/heads/feature/GEODE-7665 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=54ca6f4 ] GEODE-7858: PR.clear notify client should let the queue holder member to notify (#5677) > PR.clear notify client should let the queue holder member to notify > --- > > Key: GEODE-7858 > URL: https://issues.apache.org/jira/browse/GEODE-7858 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons, pull-request-available > > PR.clear needs to notify client at PR level, but the coordinator member maybe > not the HARegionQueue holder. Need to find and let the queue holder member to > notify. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
[ https://issues.apache.org/jira/browse/GEODE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241798#comment-17241798 ] ASF subversion and git services commented on GEODE-7845: Commit ec32386a769668bff52f6d0c50ee79c9550d3a1f in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec32386 ] GEODE-7845: Now behaving with clients of various versions. (#5645) - added functionality that would allow the tests to be run using various versions of the clients against and and new versions of the server. > Rollingupgrade should not conflict with the new ClearPRMessage > --- > > Key: GEODE-7845 > URL: https://issues.apache.org/jira/browse/GEODE-7845 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Mark Hanson >Priority: Major > Labels: GeodeCommons, pull-request-available > Fix For: 1.14.0 > > > PartitionedRegion clear introduced a new ClearPRMessage. In case of doing > rolling upgrade, the user called PR.clear. The new ClearPRMessage should not > fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241794#comment-17241794 ] ASF subversion and git services commented on GEODE-7846: Commit 6f5bbb32ebfb3b93b6e50dbe640f55a74910340b in geode's branch refs/heads/feature/GEODE-7665 from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6f5bbb3 ] GEODE-7846: Adding Stats for Partitioned Region Clear (#5391) Added stats to CachePerfStats for PR Clear - Changed clears to 'regionClears' and 'bucketClears' to differentiate between the number of times the region was cleared and the number of times a bucket was cleared in a PartitionedRegion - Added Local and Total duration stats to record how long clear has been running for a specific region, as well as how long it was spent clearing any specific member > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
[ https://issues.apache.org/jira/browse/GEODE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241796#comment-17241796 ] ASF subversion and git services commented on GEODE-7845: Commit f820e7345b5462eae9679b448ae777d9e97aa64c in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f820e73 ] GEODE-7845 blocking PR region clear if one or more server versions are too old (#5577) - if a server is running an old version when a PR clear is invoked by the client, the client will receive a ServerOperationException with a cause of ServerVersionMismatchException. > Rollingupgrade should not conflict with the new ClearPRMessage > --- > > Key: GEODE-7845 > URL: https://issues.apache.org/jira/browse/GEODE-7845 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Mark Hanson >Priority: Major > Labels: GeodeCommons, pull-request-available > Fix For: 1.14.0 > > > PartitionedRegion clear introduced a new ClearPRMessage. In case of doing > rolling upgrade, the user called PR.clear. The new ClearPRMessage should not > fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7844) Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code
[ https://issues.apache.org/jira/browse/GEODE-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-7844. -- Fix Version/s: 1.14.0 Resolution: Won't Fix We are not to use sendClearMsgByBucket solution. Close the ticket. > Refactor sendMsgByBucket and sendClearMsgByBucket not to use duplicated code > > > Key: GEODE-7844 > URL: https://issues.apache.org/jira/browse/GEODE-7844 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.14.0 > > > In PartitionedRegion class, there're 2 sendMsgByBucket() methods, one for > PutAll, another is for RemoveAll. We are adding the 3rd one for Clear. > Their logic are duplicated in most part. Need to refactor the 3 methods to > avoid duplicate code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7845) Rollingupgrade should not conflict with the new ClearPRMessage
[ https://issues.apache.org/jira/browse/GEODE-7845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241797#comment-17241797 ] ASF subversion and git services commented on GEODE-7845: Commit 2ef5165923319ef6faf02a825a6fd17ceb5f7764 in geode's branch refs/heads/feature/GEODE-7665 from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2ef5165 ] GEODE-7845: Adding a cleaner simpler test. (#5622) - Changed the test for ServerVersionMismatchException to be more readable. > Rollingupgrade should not conflict with the new ClearPRMessage > --- > > Key: GEODE-7845 > URL: https://issues.apache.org/jira/browse/GEODE-7845 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Mark Hanson >Priority: Major > Labels: GeodeCommons, pull-request-available > Fix For: 1.14.0 > > > PartitionedRegion clear introduced a new ClearPRMessage. In case of doing > rolling upgrade, the user called PR.clear. The new ClearPRMessage should not > fail. It should not be sent to the old members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7672) Partitioned Region clear will successfully update the OQL indexes
[ https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241795#comment-17241795 ] ASF subversion and git services commented on GEODE-7672: Commit 17b1a29497f9bd095126e66536ea34b0d0807d07 in geode's branch refs/heads/feature/GEODE-7665 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=17b1a29 ] GEODE-7672: add dunit test to verify OQL index after PR clear. (#5436) * require rvv lock when create index > Partitioned Region clear will successfully update the OQL indexes > - > > Key: GEODE-7672 > URL: https://issues.apache.org/jira/browse/GEODE-7672 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successfully updates the OQL indexes > > Acceptance : > * Passing Dunit tests where OQL queries using indexes return correct results > after the region is cleared > * clear operation and index updates are successful when clear operation is > executed when the puts are occurring which are trying to update the OQL index. > * Unit tests to ensure that index sizes are zero after the region is cleaned > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7679) Partitioned Region clear is successful while region is being altered
[ https://issues.apache.org/jira/browse/GEODE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241800#comment-17241800 ] ASF subversion and git services commented on GEODE-7679: Commit f3f0239ebf0f23dfa2c53e578a347036876bd92a in geode's branch refs/heads/feature/GEODE-7665 from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f3f0239 ] GEODE-7679 Partitioned Region clear is successful while region is being altered (#5516) > Partitioned Region clear is successful while region is being altered > > > Key: GEODE-7679 > URL: https://issues.apache.org/jira/browse/GEODE-7679 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successful and while alter region commands are being > executed. > Acceptance : > * DUnit tests validating the above behavior. > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7675) Partitioned Region clear should be successful when clients are present with subscription enabled
[ https://issues.apache.org/jira/browse/GEODE-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241801#comment-17241801 ] ASF subversion and git services commented on GEODE-7675: Commit 8ddd865ee40958642a5f53039a45afe2f587c924 in geode's branch refs/heads/feature/GEODE-7665 from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ddd865 ] GEODE-7675: Partitioned Region clear should be successful when clients are present with subscription enabled (#5727) > Partitioned Region clear should be successful when clients are present with > subscription enabled > > > Key: GEODE-7675 > URL: https://issues.apache.org/jira/browse/GEODE-7675 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successful when Client Subscriptions are enabled and > clients are updated with the correct region clear event. > > Acceptance : > * DUnit tests ensuring that clear operations are successful > * Ensure that all clients are getting the correct event notifications. > * HA enabled tests > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7680) Partitioned region clear operations must be successful while interacting with rebalance
[ https://issues.apache.org/jira/browse/GEODE-7680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241793#comment-17241793 ] ASF subversion and git services commented on GEODE-7680: Commit f0afbea3b67eadbd623402866a72057720f54c1d in geode's branch refs/heads/feature/GEODE-7665 from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0afbea ] GEODE-7680: PR.clear must be successful when interacting with rebalance (#5095) - Added DUnit tests to confirm that clear does not interfere with rebalance or vice versa - Test when member departs during clear/rebalance - Test when member joins during clear/rebalance - Fixed typo in PartitionedRegionClearWithExpirationDUnitTest - Fixed typo in PartitionedRegion - Call assignBucketsToPartitions() on leader colocated region during clear instead of target region Authored-by: Donal Evans > Partitioned region clear operations must be successful while interacting with > rebalance > > > Key: GEODE-7680 > URL: https://issues.apache.org/jira/browse/GEODE-7680 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Donal Evans >Priority: Major > Labels: GeodeCommons, caching-applications, > pull-request-available > Fix For: 1.14.0 > > > Clear operations are successful and while rebalance operations are ongoing. > Acceptance : > * DUnit tests validating the above behavior. > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241802#comment-17241802 ] Dave Barnes commented on GEODE-8738: [~alberto.gomez] I merged the pull request. I'll leave it to you to 'resolve' this ticket, if the PR completes your work. Thanks! > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241826#comment-17241826 ] ASF GitHub Bot commented on GEODE-8644: --- demery-pivotal opened a new pull request #5796: URL: https://github.com/apache/geode/pull/5796 SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() now waits until the queues are drained rather than sleeping for 2 seconds before asserting. 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 > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8644: -- Labels: pull-request-available (was: ) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8753) Redis Acceptance Tests Hang
Bill Burcham created GEODE-8753: --- Summary: Redis Acceptance Tests Hang Key: GEODE-8753 URL: https://issues.apache.org/jira/browse/GEODE-8753 Project: Geode Issue Type: Bug Components: redis Reporter: Bill Burcham Redis acceptance tests do not finish in time in CI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241828#comment-17241828
]
ASF GitHub Bot commented on GEODE-8752:
---
demery-pivotal opened a new pull request #5797:
URL: https://github.com/apache/geode/pull/5797
When revoking a persistent member,
PersistentPartitionedRegionDistributedTest now uses the to-be-revoked
member's actual inet address in the revocation pattern.
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
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8752) PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer() test uses wrong address to revoke
[
https://issues.apache.org/jira/browse/GEODE-8752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8752:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses wrong address to revoke
> ---
>
> Key: GEODE-8752
> URL: https://issues.apache.org/jira/browse/GEODE-8752
> 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
>
> PersistentPartitionedRegionDistributedTest.missingDiskStoreCanBeRevokedBeforeStartingServer()
> test uses the wrong address to revoke persistent members.
> The product uses {{LocalHostUtil.getLocalHost()}} in its member IDs.
> Once upon a time, the test used {{InetAddress.getLocalHost()}} to get the
> address to revoke, but in some circumstances that can return an in
> appropriate address.
> GEODE-7029 changed the test to use a different mechanism to find the address
> to revoke: Walk through all available addresses on all available interfaces
> to find a non-loopback IPv4 address. But in some circumstances that can
> return an address other than the one used in the to-be-revoked member's ID,
> and the test fails.
> Both of these methods of getting the revoke address rest on unwarranted
> assumptions. The test should instead query the member to discover the address
> used in its actual ID, then use that address to revoke the member.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241827#comment-17241827
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#617|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-results/distributedTest/1606761269/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-artifacts/1606761269/distributedtestfiles-OpenJDK11-1.14.0-build.0519.tgz].
> 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] [Commented] (GEODE-8753) Redis Acceptance Tests Hang
[ https://issues.apache.org/jira/browse/GEODE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241829#comment-17241829 ] Geode Integration commented on GEODE-8753: -- Seen in [AcceptanceTestOpenJDK8 #595|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/595] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-results/acceptanceTest/1606761008/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-artifacts/1606761008/acceptancetestfiles-OpenJDK8-1.14.0-build.0519.tgz]. > Redis Acceptance Tests Hang > --- > > Key: GEODE-8753 > URL: https://issues.apache.org/jira/browse/GEODE-8753 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bill Burcham >Priority: Major > > Redis acceptance tests do not finish in time in CI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8753) Redis Acceptance Tests Hang
[ https://issues.apache.org/jira/browse/GEODE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241832#comment-17241832 ] Geode Integration commented on GEODE-8753: -- Seen in [AcceptanceTestOpenJDK11 #601|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/601] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0522/test-results/acceptanceTest/1606777543/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0522/test-artifacts/1606777543/acceptancetestfiles-OpenJDK11-1.14.0-build.0522.tgz]. > Redis Acceptance Tests Hang > --- > > Key: GEODE-8753 > URL: https://issues.apache.org/jira/browse/GEODE-8753 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bill Burcham >Priority: Major > > Redis acceptance tests do not finish in time in CI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8753) Redis Acceptance Tests Hang
[ https://issues.apache.org/jira/browse/GEODE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241830#comment-17241830 ] Geode Integration commented on GEODE-8753: -- Seen in [AcceptanceTestOpenJDK11 #599|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/599] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0520/test-results/acceptanceTest/1606766838/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0520/test-artifacts/1606766838/acceptancetestfiles-OpenJDK11-1.14.0-build.0520.tgz]. > Redis Acceptance Tests Hang > --- > > Key: GEODE-8753 > URL: https://issues.apache.org/jira/browse/GEODE-8753 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bill Burcham >Priority: Major > > Redis acceptance tests do not finish in time in CI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag updated GEODE-8745: --- Fix Version/s: 1.14.0 > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-5782:
Issue Type: Bug (was: Test)
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.14.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-8745. Resolution: Fixed > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reopened GEODE-5782:
-
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.14.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241836#comment-17241836
]
Geode Integration commented on GEODE-5782:
--
Seen in [WindowsCoreIntegrationTestOpenJDK11
#593|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/593]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-results/integrationTest/1606768270/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0519/test-artifacts/1606768270/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0519.tgz].
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.14.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag closed GEODE-8745. -- > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241837#comment-17241837
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#619|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/619]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0521/test-results/distributedTest/1606773730/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0521/test-artifacts/1606773730/distributedtestfiles-OpenJDK11-1.14.0-build.0521.tgz].
> 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)
[GitHub] [geode-kafka-connector] yrashish opened a new issue #5: Upgrade Geode Version
yrashish opened a new issue #5: URL: https://github.com/apache/geode-kafka-connector/issues/5 Any specific reason for using geode version 1.9.0. Latest available version is 1.13.x. Let me know if we can upgrade the version or there is some dependency? 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
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241841#comment-17241841
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#623|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/623]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0525/test-results/distributedTest/1606853195/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0525/test-artifacts/1606853195/distributedtestfiles-OpenJDK11-1.14.0-build.0525.tgz].
> 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)
[GitHub] [geode-kafka-connector] yrashish opened a new issue #6: Add support for Java 11
yrashish opened a new issue #6: URL: https://github.com/apache/geode-kafka-connector/issues/6 Java SE 11 is the only LTS release so it makes sense to upgrade java version from 8 to 11. Thoughts? 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
[GitHub] [geode-kafka-connector] yrashish opened a new issue #7: Remove Zookeeper dependency
yrashish opened a new issue #7: URL: https://github.com/apache/geode-kafka-connector/issues/7 This issue is for future reference. As per [this](https://www.confluent.io/blog/removing-zookeeper-dependency-in-kafka/) Apache Kafka will replace its usage of Apache ZooKeeper with its own built-in consensus layer. So we may need to remove any Zookeeper dependency(integration test etc.) from the connector. Detailed instructions given [here](https://www.confluent.io/blog/how-to-prepare-for-kip-500-kafka-zookeeper-removal-guide/). 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
[jira] [Commented] (GEODE-8753) Redis Acceptance Tests Hang
[ https://issues.apache.org/jira/browse/GEODE-8753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241883#comment-17241883 ] Geode Integration commented on GEODE-8753: -- Seen in [AcceptanceTestOpenJDK8 #602|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/602] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0526/test-results/acceptanceTest/1606857049/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0526/test-artifacts/1606857049/acceptancetestfiles-OpenJDK8-1.14.0-build.0526.tgz]. > Redis Acceptance Tests Hang > --- > > Key: GEODE-8753 > URL: https://issues.apache.org/jira/browse/GEODE-8753 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bill Burcham >Priority: Major > > Redis acceptance tests do not finish in time in CI -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
[
https://issues.apache.org/jira/browse/GEODE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241882#comment-17241882
]
Geode Integration commented on GEODE-8411:
--
Seen in [DistributedTestOpenJDK11
#621|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/621]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0523/test-results/distributedTest/1606845456/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0523/test-artifacts/1606845456/distributedtestfiles-OpenJDK11-1.14.0-build.0523.tgz].
> CI Failure: Jetty9CachingClientServerTest.
> containersShouldShareDataRemovals() fails with comparison failure
>
>
> Key: GEODE-8411
> URL: https://issues.apache.org/jira/browse/GEODE-8411
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI
> run.
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldShareDataRemovals FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241898#comment-17241898 ] Geode Integration commented on GEODE-8740: -- Seen in [UpgradeTestOpenJDK11 #603|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/603] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0522/test-results/upgradeTest/1606778549/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0522/test-artifacts/1606778549/upgradetestfiles-OpenJDK11-1.14.0-build.0522.tgz]. > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241908#comment-17241908
]
ASF GitHub Bot commented on GEODE-8742:
---
DonalEvans commented on a change in pull request #5777:
URL: https://github.com/apache/geode/pull/5777#discussion_r533686032
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/wancommand/ListGatewaysCommandDUnitTest.java
##
@@ -450,6 +450,31 @@ public void
testListGatewaysReceiversOnlyFalseAndSendersOnlyFalseReturnsSendersA
.hasRowSize(expectedGwReceiverSectionSize).hasColumns().contains("Port",
"Member");
}
+ @Test
+ public void testListGatewaysWithOneDispatcherThread() {
+String command =
+"create gateway-sender --id=ln_Serial --remote-distributed-system-id=2
--dispatcher-threads=1";
+
+int lnPort = locatorSite1.getPort();
+int nyPort = locatorSite2.getPort();
Review comment:
This variable is never used.
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueueDUnitTest.java
##
@@ -110,18 +111,18 @@ public void unprocessedTokensMapShouldDrainCompletely()
throws Exception {
// Give the unprocessedTokens map time to empty
Thread.sleep(2000);
-int numUnprocessedTokensVM4 = vm4.invoke(() ->
unprocessedTokensSize("ln"));
+long numUnprocessedTokensVM4 = vm4.invoke(() ->
unprocessedTokensSize("ln"));
assertThat(numUnprocessedTokensVM4).isEqualTo(0);
-int numUnprocessedTokensVM5 = vm5.invoke(() ->
unprocessedTokensSize("ln"));
+long numUnprocessedTokensVM5 = vm5.invoke(() ->
unprocessedTokensSize("ln"));
assertThat(numUnprocessedTokensVM5).isEqualTo(0);
}
- private int unprocessedTokensSize(String senderId) {
+ private long unprocessedTokensSize(String senderId) {
AbstractGatewaySender sender = (AbstractGatewaySender)
findGatewaySender(senderId);
-SerialGatewaySenderEventProcessor processor =
-(SerialGatewaySenderEventProcessor) sender.getEventProcessor();
-return processor.numUnprocessedEventTokens();
+AbstractGatewaySenderEventProcessor processor =
+sender.getEventProcessor();
+return processor.getNumEventsDispatched();
Review comment:
It appears that the name of this method no longer matches what it's
doing. The method returns the number of events dispatched, not the number of
unprocessed events. This also impacts tests that use this method, since they
are now asserting something different.
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderImpl.java
##
@@ -117,15 +117,8 @@ private void start(boolean cleanQueues) {
}
protected AbstractGatewaySenderEventProcessor createEventProcessor(boolean
cleanQueues) {
-AbstractGatewaySenderEventProcessor eventProcessor;
-if (getDispatcherThreads() > 1) {
- eventProcessor = new RemoteConcurrentSerialGatewaySenderEventProcessor(
- SerialGatewaySenderImpl.this, getThreadMonitorObj(), cleanQueues);
-} else {
- eventProcessor = new
RemoteSerialGatewaySenderEventProcessor(SerialGatewaySenderImpl.this,
- getId(), getThreadMonitorObj(), cleanQueues);
-}
-return eventProcessor;
+return new RemoteConcurrentSerialGatewaySenderEventProcessor(
+SerialGatewaySenderImpl.this, getThreadMonitorObj(), cleanQueues);
Review comment:
Would it be possible to address the underlying problem with using
`RemoteSerialGatewaySenderEventProcessor` rather than simply not using it?
There appears to be an NPE thrown when calling
`GatewaySenderMXBean.isConnected()` on the `GatewaySenderMXBean` proxy in
`ListGatewayCommand` when `dispatcher-threads=1`, which this change does not
directly address. It would be better to address the root cause of this issue if
possible rather than just avoiding it, I think.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>l
[jira] [Commented] (GEODE-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241911#comment-17241911 ] ASF GitHub Bot commented on GEODE-8693: --- pdxcodemonkey merged pull request #690: URL: https://github.com/apache/geode-native/pull/690 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 > C++ native client Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > -- > > Key: GEODE-8693 > URL: https://issues.apache.org/jira/browse/GEODE-8693 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > According to the Apache Geode Native C++ API documentation, the > FunctionService.onServers() function will throw an Exception if one of the > servers goes down while dispatching or executing the function on the server. > Nevertheless, currently no exception is thrown in that case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[ https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241916#comment-17241916 ] ASF GitHub Bot commented on GEODE-8521: --- dschneider-pivotal opened a new pull request #5798: URL: https://github.com/apache/geode/pull/5798 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 > Add P2P message reader threads to thread monitoring > --- > > Key: GEODE-8521 > URL: https://issues.apache.org/jira/browse/GEODE-8521 > Project: Geode > Issue Type: Wish > Components: messaging >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Add P2P message reader threads to thread monitoring to help with identifying > stuck P2P message readers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8754) Deserialization Error in .NET DataInput::ReadObject
Michael Martell created GEODE-8754: -- Summary: Deserialization Error in .NET DataInput::ReadObject Key: GEODE-8754 URL: https://issues.apache.org/jira/browse/GEODE-8754 Project: Geode Issue Type: Bug Components: native client Reporter: Michael Martell Using the IDataSerializable interface for user defined .NET types sometimes fails in a Release build. Specifically, the DataInput::ReadObject() function may fail in a Release build. Note: DataInput::ReadObject() never fails in a Debug build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241926#comment-17241926
]
ASF GitHub Bot commented on GEODE-8202:
---
alb3rtobr commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r533779942
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -472,6 +516,12 @@ private GatewaySenderException
getInitializeConnectionExceptionToThrow(
"No available connection was found, but the following active
servers exist: %s",
buffer.toString());
}
+ if (this.sender.getEnforceThreadsConnectSameReceiver()) {
+if (Pattern.compile("Cannot get connection to .* after .* attempts.")
Review comment:
I have added a commit that extracts the exception message to a variable,
this will avoid breaking the check if the text is changed.
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
> New option for serial gw sender threads start when receivers share ip and port
> --
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8634:
--
Labels: pull-request-available (was: )
> CI failure: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCause(AsyncInvocationTimeoutDistributedTest.java:124)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.1-build.0380/test-results/distributedTest/1603276549/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.1-build.0380/test-artifacts/1603276549/distributedtestfiles-OpenJDK8-1.13.1-build.
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241929#comment-17241929
]
ASF GitHub Bot commented on GEODE-8634:
---
kirklund opened a new pull request #5799:
URL: https://github.com/apache/geode/pull/5799
Null out latch and threadId before each test.
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: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> 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 sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCause(AsyncInvocationTimeoutDistributedTest.java:124)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-
[jira] [Updated] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8755:
--
Labels: GeodeOperationAPI (was: )
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
Dale Emery created GEODE-8755:
-
Summary: BundledJarsJUnitTest writes bundled_jars.txt file to
wrong dir
Key: GEODE-8755
URL: https://issues.apache.org/jira/browse/GEODE-8755
Project: Geode
Issue Type: Test
Components: tests
Reporter: Dale Emery
BundledJarsJUnitTest instructs the user to examine and vet the
{{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
But since GEODE-8637, which causes each test class to run in a unique working
directory, the file now ends up in a directory other than the one in the
instructions, like:
{{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-8755:
-
Assignee: Dale Emery
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-8755:
--
Affects Version/s: 1.14.0
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241932#comment-17241932 ] ASF GitHub Bot commented on GEODE-8644: --- demery-pivotal merged pull request #5796: URL: https://github.com/apache/geode/pull/5796 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 > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241934#comment-17241934 ] ASF subversion and git services commented on GEODE-8644: Commit 4ac3b78174f0298f1c207b626e19a7fb92e0f726 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4ac3b78 ] GEODE-8644: Change sleep to awaitility in sender queue test (#5796) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() now waits until the queues are drained rather than sleeping for 2 seconds before asserting. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8755:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> 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
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8755) BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
[
https://issues.apache.org/jira/browse/GEODE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241941#comment-17241941
]
ASF GitHub Bot commented on GEODE-8755:
---
demery-pivotal opened a new pull request #5800:
URL: https://github.com/apache/geode/pull/5800
BundledJarsJUnitTest once again writes the bundled_jars.txt file to the
integrationTest dir, where the failure message instructs the user to
look for it.
Authored-by: Dale Emery
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
> BundledJarsJUnitTest writes bundled_jars.txt file to wrong dir
> --
>
> Key: GEODE-8755
> URL: https://issues.apache.org/jira/browse/GEODE-8755
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI
>
> BundledJarsJUnitTest instructs the user to examine and vet the
> {{geode-assembly/build/integrationTest/bundled_jars.txt}} file.
> But since GEODE-8637, which causes each test class to run in a unique working
> directory, the file now ends up in a directory other than the one in the
> instructions, like:
> {{geode-assembly/build/integrationTest/test-worker-00014/bundled_jars.txt}}.
> This is confusing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241945#comment-17241945
]
ASF subversion and git services commented on GEODE-8721:
Commit 956c9aa66328a8bed14892f16d230f8d4f6c8105 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=956c9aa ]
GEODE-8721: member that should become coordinator never detects loss of current
coordinator (#5758)
* GEODE-8721: member that should become coordinator never detects loss of
current coordinator
If a server is in the process of performing an availability check on
another server we shouldn't update the contact timestamp for
the suspected server based on gossip from another server. Doing so
will make the availability check pass and send out another gossip
message that would likewise update their timestamps for the suspected
server, perpetuating the notion that the suspect is still around.
* added VisibleForTesting
(cherry picked from commit b7afc604b9c2fafe4388dcdcf05fc7ec49c0ce86)
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8721:
--
Fix Version/s: 1.13.2
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241946#comment-17241946
]
ASF subversion and git services commented on GEODE-8721:
Commit 956c9aa66328a8bed14892f16d230f8d4f6c8105 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=956c9aa ]
GEODE-8721: member that should become coordinator never detects loss of current
coordinator (#5758)
* GEODE-8721: member that should become coordinator never detects loss of
current coordinator
If a server is in the process of performing an availability check on
another server we shouldn't update the contact timestamp for
the suspected server based on gossip from another server. Doing so
will make the availability check pass and send out another gossip
message that would likewise update their timestamps for the suspected
server, perpetuating the notion that the suspect is still around.
* added VisibleForTesting
(cherry picked from commit b7afc604b9c2fafe4388dcdcf05fc7ec49c0ce86)
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8721) member that should become coordinator never detects loss of current coordinator
[
https://issues.apache.org/jira/browse/GEODE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8721:
--
Fix Version/s: 1.12.1
> member that should become coordinator never detects loss of current
> coordinator
> ---
>
> Key: GEODE-8721
> URL: https://issues.apache.org/jira/browse/GEODE-8721
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.14.0
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available, release-blocker
> Fix For: 1.12.1, 1.14.0, 1.13.2
>
>
> During a network partition a server that should have become membership
> coordinator and shut down its side of the partition never detected the loss
> of a server on the other side of the partition. Instead it continually
> performed availability checks on that other server and the checks passed.
> Its log file had continually increasing timestamps for when it claimed the
> other server had contacted it, which was not possible due to the network
> partition (which was formed through iptable manipulation).
> At least one other server on its side of the network partition was doing the
> same thing. It looks like they were interfering with each others
> availability checks in some way.
> {noformat}
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.227 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:12 PDT 2020
> locatorp1_26023/system.log: [info 2020/10/20 22:23:16.228 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25995/system.log: [info 2020/10/20 22:23:16.229 PDT receiver,rs-F21040449a0i3large-72-61636> tid=0x23] No longer suspecting
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.212 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:14 PDT 2020
> bridgep1_25998/system.log: [info 2020/10/20 22:23:17.213 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Availability check passed
> for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> locatorp1_26023/system.log: [info 2020/10/20 22:23:17.232 PDT Timer-2,rs-F21040449a0i3large-72-47481> tid=0x23] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25998/system.log: [info 2020/10/20 22:23:18.215 PDT Timer-2,rs-F21040449a0i3large-72-2074> tid=0x21] Performing availability
> check for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000
> reason=Unable to send messages to this member via JGroups
> bridgep1_25995/system.log: [info 2020/10/20 22:23:21.006 PDT Timer-2,rs-F21040449a0i3large-72-61636> tid=0x21] Availability check detected
> recent message traffic for suspect member
> 10.32.109.233(locatorp2_host2_21762:21762:locator):41000 at time Tue
> Oct 20 22:23:16 PDT 2020
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241956#comment-17241956
]
ASF GitHub Bot commented on GEODE-8202:
---
DonalEvans commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r533809728
##
File path:
geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
##
@@ -348,11 +349,56 @@ public void destroyConnection() {
}
}
+ Connection retryInitializeConnection(Connection con) {
+final boolean isDebugEnabled = logger.isDebugEnabled();
+ServerLocation server = this.sender.getServerLocation();
+String connectedServerId = con.getEndpoint().getMemberId().getUniqueId();
+String expectedServerId = this.processor.getExpectedReceiverUniqueId();
+boolean connectedToExpectedReceiver =
connectedServerId.equals(expectedServerId);
+if (expectedServerId.equals("")) {
+ if (isDebugEnabled) {
+logger.debug("First dispatcher connected to endpoint " +
connectedServerId);
+ }
+ this.processor.setExpectedReceiverUniqueId(connectedServerId);
+ connectedToExpectedReceiver = true;
+}
+int attempt = 0;
+final int maxAttempts = 5;
Review comment:
I feel a little uneasy about the idea of something that could fail at
random just due to bad luck. There's a non-zero (albeit small) chance that we
would never get the "right" receiver using this approach, and the number of
retries necessary to ensure we have some minimum probability of getting the
right receiver increases rapidly with each receiver that's sharing the same ip
and port.
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
> New option for serial gw sender threads start when receivers share ip and port
> --
>
> Key: GEODE-8202
> URL: https://issues.apache.org/jira/browse/GEODE-8202
> Project: Geode
> Issue Type: Improvement
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
>
> RFC:
> [https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start|https://cwiki.apache.org/confluence/display/GEODE/New+option+for+serial+gw+sender+dispatcher+threads+start]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241959#comment-17241959 ] Geode Integration commented on GEODE-8740: -- Seen in [Benchmark_base #486|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/486]. > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241958#comment-17241958 ] Geode Integration commented on GEODE-8740: -- Seen in [Benchmark_with_ssl #487|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_with_ssl/builds/487]. > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8202) New option for serial gw sender threads start when receivers share ip and port
[
https://issues.apache.org/jira/browse/GEODE-8202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17241960#comment-17241960
]
ASF GitHub Bot commented on GEODE-8202:
---
DonalEvans commented on a change in pull request #5600:
URL: https://github.com/apache/geode/pull/5600#discussion_r533812068
##
File path:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherJUnitTest.java
##
@@ -77,4 +132,160 @@ public void
getConnectionShouldCreateNewConnectionWhenServerIsNull() {
verify(dispatcher, times(1)).initializeConnection();
verify(dispatcher, times(2)).getConnectionLifeCycleLock();
}
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializeParallelSenderConnection_retriesAreNotUsed()
{
+when(senderMock.isParallel()).thenReturn(true);
+
+eventDispatcher = new
GatewaySenderEventRemoteDispatcher(eventProcessorMock, null);
+GatewaySenderEventRemoteDispatcher dispatcherSpy = spy(eventDispatcher);
+dispatcherSpy.initializeConnection();
+
+verify(senderMock, times(0)).getLockForConcurrentDispatcher();
+verify(senderMock, times(1)).setServerLocation(any());
+verify(poolMock, times(1)).acquireConnection();
+verify(dispatcherSpy, times(0)).retryInitializeConnection(connectionMock);
+ }
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializingConnectionOfSerialSenderWithOptionSetToFalse_retriesAreNotUsed()
{
Review comment:
This test name might be better as
"intializeConnectionWithSerialSenderAndEnforceThreadsConnectSameRecieverFalseDoesNotRetryInitializeConnection".
##
File path:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherJUnitTest.java
##
@@ -77,4 +132,160 @@ public void
getConnectionShouldCreateNewConnectionWhenServerIsNull() {
verify(dispatcher, times(1)).initializeConnection();
verify(dispatcher, times(2)).getConnectionLifeCycleLock();
}
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializeParallelSenderConnection_retriesAreNotUsed()
{
+when(senderMock.isParallel()).thenReturn(true);
+
+eventDispatcher = new
GatewaySenderEventRemoteDispatcher(eventProcessorMock, null);
+GatewaySenderEventRemoteDispatcher dispatcherSpy = spy(eventDispatcher);
+dispatcherSpy.initializeConnection();
+
+verify(senderMock, times(0)).getLockForConcurrentDispatcher();
+verify(senderMock, times(1)).setServerLocation(any());
+verify(poolMock, times(1)).acquireConnection();
+verify(dispatcherSpy, times(0)).retryInitializeConnection(connectionMock);
+ }
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializingConnectionOfSerialSenderWithOptionSetToFalse_retriesAreNotUsed()
{
+when(senderMock.getEnforceThreadsConnectSameReceiver()).thenReturn(false);
+
+when(connectionMock.getEndpoint()).thenReturn(endpointMock);
+when(endpointMock.getMemberId()).thenReturn(memberIdMock);
+when(memberIdMock.getUniqueId()).thenReturn("receiverId");
+
+eventDispatcher = new
GatewaySenderEventRemoteDispatcher(eventProcessorMock, null);
+GatewaySenderEventRemoteDispatcher dispatcherSpy = spy(eventDispatcher);
+dispatcherSpy.initializeConnection();
+
+verify(senderMock, times(1)).getLockForConcurrentDispatcher();
+verify(senderMock, times(1)).getEnforceThreadsConnectSameReceiver();
+verify(poolMock, times(1)).acquireConnection();
+verify(dispatcherSpy, times(0)).retryInitializeConnection(connectionMock);
+ }
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializingConnectionOfSerialSenderWithOptionSetToTrue_firstThreadObtainsTheReceiverId()
{
Review comment:
This test might be better named
"initializeConnectionWithSerialSenderAndEnforceThreadsConnectSameReceiverTrueAndNoExpectedReceiverSetsReceiverIdAndDoesNotReacquireConnection".
##
File path:
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcherJUnitTest.java
##
@@ -77,4 +132,160 @@ public void
getConnectionShouldCreateNewConnectionWhenServerIsNull() {
verify(dispatcher, times(1)).initializeConnection();
verify(dispatcher, times(2)).getConnectionLifeCycleLock();
}
+
+ @Test
+ public void
enforceThreadsConnectSameReceiver_initializeParallelSenderConnection_retriesAreNotUsed()
{
+when(senderMock.isParallel()).thenReturn(true);
+
+eventDispatcher = new
GatewaySenderEventRemoteDispatcher(eventProcessorMock, null);
+GatewaySenderEventRemoteDispatcher dispatcherSpy = spy(eventDispatcher);
+dispatcherSpy.initializeConnection();
+
+verify(senderMock, times(0)).getLockForConcurrentDispatcher();
+verify(senderMock, times(1)).setServerLocation(any());
+verify(poolMock, times(1)).acquireConnection();
+verify(dispatcherSpy, times(0)).retryInitializeConnection(connect
[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=17241965#comment-17241965
]
ASF GitHub Bot commented on GEODE-8667:
---
gesterzhou commented on a change in pull request #5689:
URL: https://github.com/apache/geode/pull/5689#discussion_r533822731
##
File path: geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java
##
@@ -5789,9 +5789,8 @@ boolean needsCompaction() {
if (((rv / (double) rvHWMtmp) * 100) <= parent.getCompactionThreshold())
{
return true;
}
-} else {
Review comment:
Darrel and I discussed again. We might need to re-fix it the other way:
Since the trouble is caused by offline compaction wrote totalCount=0 into
krf, there's a potential bug that we restart with totalCount=0, but
totalLiveCount=1, then with your current code change this oplog will never get
a chance to compact until the only live entry is destroyed.
So a better fix maybe: when restart and found totalCount=0, then update
totalCount to be totalLiveCount. With this fix, you don't need to change
needsCompaction() any more.
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)
