[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047285#comment-17047285 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/develop from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047284#comment-17047284 ] ASF subversion and git services commented on GEODE-7771: Commit 51a0c65f95ac465db1f9703a6a8055730c65e828 in geode's branch refs/heads/develop from mkevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=51a0c65 ] GEODE-7771: change getting cache in getLuceneIndex (#4702) * GEODE-7771: change getting cache in getLuceneIndex * simplify test > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7771) LuceneQueryFunction.getLuceneIndex should be passed in the Cache
[ https://issues.apache.org/jira/browse/GEODE-7771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-7771. --- Fix Version/s: 1.13.0 Resolution: Fixed > LuceneQueryFunction.getLuceneIndex should be passed in the Cache > > > Key: GEODE-7771 > URL: https://issues.apache.org/jira/browse/GEODE-7771 > Project: Geode > Issue Type: Task > Components: lucene >Reporter: Jason Huynh >Assignee: Mario Kevo >Priority: Major > Labels: beginner, newb, pull-request-available, starter > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently the getLuceneIndex method is grabbing a reference of the cache > through the region.getCache() (deprecated for some reason) method. We can > probably just pass in the cache from the caller (the function context has a > getCache() method that can be used instead). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=17047277#comment-17047277 ] ASF subversion and git services commented on GEODE-7682: Commit 658afb35d4ac4f04db8e69f59762112f746e1751 in geode's branch refs/heads/feature/GEODE-7682 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=658afb3 ] GEODE-7682: add clear API for PR > 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 >Priority: Major > Labels: GeodeCommons > > 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] [Resolved] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-7815. Fix Version/s: 1.13.0 Resolution: Fixed > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-4194) DiskDistributedNoAckAsyncOverflowRegionDUnitTest testNBRegionDestructionDuringGetInitialImage hangs
[ https://issues.apache.org/jira/browse/GEODE-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson reassigned GEODE-4194: -- Assignee: Mark Hanson (was: Kirk Lund) > DiskDistributedNoAckAsyncOverflowRegionDUnitTest > testNBRegionDestructionDuringGetInitialImage hangs > --- > > Key: GEODE-4194 > URL: https://issues.apache.org/jira/browse/GEODE-4194 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Lynn Gallinat >Assignee: Mark Hanson >Priority: Major > Labels: flaky > > This test caused concourse to timeout when it hung: > Started @ 2018-01-03 18:49:16.700 + > 2018-01-03 19:21:00.165 + > org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest > testNBRegionDestructionDuringGetInitialImage > Ended @ 2018-01-03 20:55:26.951 + -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047104#comment-17047104
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/feature/GEODE-7808b from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047108#comment-17047108
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/feature/GEODE-7808b from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047106#comment-17047106 ] ASF subversion and git services commented on GEODE-7808: Commit ccab59dad5789bb77139209eeb313600f88ea6f2 in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccab59d ] GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047110#comment-17047110 ] ASF subversion and git services commented on GEODE-7808: Commit ccab59dad5789bb77139209eeb313600f88ea6f2 in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ccab59d ] GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047109#comment-17047109 ] ASF subversion and git services commented on GEODE-7808: Commit 2f7a825042781c167390f805d3aa15b59992e723 in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f7a825 ] Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047105#comment-17047105 ] ASF subversion and git services commented on GEODE-7808: Commit 2f7a825042781c167390f805d3aa15b59992e723 in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2f7a825 ] Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047107#comment-17047107 ] ASF subversion and git services commented on GEODE-7815: Commit 8498329c10f66d8aeca01eefc9c3abf646fe8d2c in geode's branch refs/heads/feature/GEODE-7808b from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8498329 ] GEODE-7815: Document setting a GEODE_HOME env variable (#4732) > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047103#comment-17047103 ] ASF subversion and git services commented on GEODE-7815: Commit 8498329c10f66d8aeca01eefc9c3abf646fe8d2c in geode's branch refs/heads/feature/GEODE-7808b from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8498329 ] GEODE-7815: Document setting a GEODE_HOME env variable (#4732) > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7781) TCPConduitDUnitTest.basicAcceptConnection fails
[
https://issues.apache.org/jira/browse/GEODE-7781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047102#comment-17047102
]
Mark Hanson commented on GEODE-7781:
More mass-test run failures
{noformat}
basicAcceptConnection[1]
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/682
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/663
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/607
{noformat}
{noformat}
org.apache.geode.internal.tcp.TCPConduitDUnitTest > basicAcceptConnection[1]
FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2199
[fatal 2020/02/24 07:16:39.211 GMT tid=133] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Conduit has been stopped
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:991)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1690)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1472)
at java.lang.Thread.run(Thread.java:748) {noformat}
> TCPConduitDUnitTest.basicAcceptConnection fails
> ---
>
> Key: GEODE-7781
> URL: https://issues.apache.org/jira/browse/GEODE-7781
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Ivan Godwin
>Priority: Major
> Labels: flaky
>
> TCPConduitDUnitTest.basicAcceptConnection failed with the following
> stacktrace:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1557
> {code:java}
> org.apache.geode.internal.tcp.TCPConduitDUnitTest > basicAcceptConnection[0]
> FAILED
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on 172.17.0.10(1:locator):41001 started at Fri
> Feb 07 21:28:15 GMT 2020: for testing, caused by
> org.apache.geode.ForcedDisconnectException: for testing
> Caused by:
> org.apache.geode.ForcedDisconnectException: for testing
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047093#comment-17047093 ] ASF subversion and git services commented on GEODE-7808: Commit 38341c1ee020b89a2b28063f6ea1032b10d927eb in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=38341c1 ] Squashed merge of feature/GEODE-7808 removed HostAddress renamed LocatorAddress to HostAndPort modified TcpClient methods to take a HostAndPort argument instead of InetAddress modified SocketCreator to take a HostAndPort argument instead of InetAddress > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047094#comment-17047094 ] ASF subversion and git services commented on GEODE-7808: Commit ef36cb44890af6d0655c2bef2d516c8538d514cb in geode's branch refs/heads/feature/GEODE-7808b from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ef36cb4 ] GEODE-7808 - standardize on use of HostAndPort for connection formation This continues a previous PR that passed and was approved for merge. This commit raises up several methods from SocketCreator into the TcpSocketCreator interface. This is an intermediate commit. A subsequent commit will refactor TcpSocketCreator to separate the client and server methods for creating server-sockets and client connections to server-sockets. > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7681) Gather Partitioned Region clear operation performance metrics
[ https://issues.apache.org/jira/browse/GEODE-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047068#comment-17047068 ] ASF subversion and git services commented on GEODE-7681: Commit 5ccefac5f69df41375e6762ddf47ed0c3a729b65 in geode's branch refs/heads/feature/GEODE-7681 from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5ccefac ] GEODE-7681: Initial draft of performance dunit Authored-by: Jianxia Chen > Gather Partitioned Region clear operation performance metrics > - > > Key: GEODE-7681 > URL: https://issues.apache.org/jira/browse/GEODE-7681 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons > > We need to have a table which gives us an idea how long a region clear > operation takes corresponding to how large a region is. > We will also need to take measurements with persistence enabled and > redundancy variations. > > Please attach the numbers and other findings to this Jira and the RFC > mentioned in GEODE-7665 > [[https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region]] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7681) Gather Partitioned Region clear operation performance metrics
[ https://issues.apache.org/jira/browse/GEODE-7681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen reassigned GEODE-7681: --- Assignee: Jianxia Chen > Gather Partitioned Region clear operation performance metrics > - > > Key: GEODE-7681 > URL: https://issues.apache.org/jira/browse/GEODE-7681 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons > > We need to have a table which gives us an idea how long a region clear > operation takes corresponding to how large a region is. > We will also need to take measurements with persistence enabled and > redundancy variations. > > Please attach the numbers and other findings to this Jira and the RFC > mentioned in GEODE-7665 > [[https://cwiki.apache.org/confluence/display/GEODE/Support+for+clear+operation+on+partitioned+region]] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7827) show jmx manager info by "/management/v1/members/" in REST API for Management
Gang Yan created GEODE-7827: --- Summary: show jmx manager info by "/management/v1/members/" in REST API for Management Key: GEODE-7827 URL: https://issues.apache.org/jira/browse/GEODE-7827 Project: Geode Issue Type: Improvement Components: management, rest (admin) Reporter: Gang Yan need to get more information about which locator is running with jmx-manager currently, there is only one way to find it, it is just in the output of "gfsh connect", to find out some similar words:"Successfully connected to: JMX Manager [host=10.118.20.82, port=1099]" it is not an explicit way to the users. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7826) met error when run rebalance by REST API on running 2 locators of 1 vm
Gang Yan created GEODE-7826:
---
Summary: met error when run rebalance by REST API on running 2
locators of 1 vm
Key: GEODE-7826
URL: https://issues.apache.org/jira/browse/GEODE-7826
Project: Geode
Issue Type: Bug
Components: management, rest (admin)
Reporter: Gang Yan
the reproduced steps:
1. gfsh start locator --port=0 --http-service-port=8081 --name=loc1
2. gfsh start locator --port=0 --name=loc2
3. gfsh start server --server-port=0 --name=s1
4. gfsh create region --name=/regionTest --type=PARTITION
5. java code to put 10 million data to regionTest
6. gfsh start server --server-port=0 --name=s2
7.run rebalance by [post] "
http://127.0.0.1:7070/management/v1/operations/rebalances;
8. run [GET]"http://127.0.0.1:8081/management/v1/operations/rebalances;
9. met the following error
{code:java}
{
"statusCode": "ERROR",
"links": {
"self":
"http://127.0.0.1:7070/management/v1/operations/rebalances/3bb2f394-3d21-4076-8c24-3cf3ce7bbbea;,
"list": "http://127.0.0.1:7070/management/v1/operations/rebalances;
},
"operationStart": "2020-02-26T22:06:44.601Z",
"operationEnd": "2020-02-26T22:06:44.603Z",
"operationId": "3bb2f394-3d21-4076-8c24-3cf3ce7bbbea",
"operation": {
"simulate": false
},
"throwable": {
"stackTrace": [
{
"methodName": "getMemberRegionList",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 208,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "executeRebalanceOnDS",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 326,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "perform",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 91,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "lambda$submit$0",
"fileName": "OperationManager.java",
"lineNumber": 67,
"className":
"org.apache.geode.management.internal.operation.OperationManager",
"nativeMethod": false
},
{
"methodName": "run",
"fileName": "CompletableFuture.java",
"lineNumber": 1590,
"className":
"java.util.concurrent.CompletableFuture$AsyncSupply",
"nativeMethod": false
},
{
"methodName": "run",
"fileName": "Thread.java",
"lineNumber": 748,
"className": "java.lang.Thread",
"nativeMethod": false
}
]
}
}
{code}
expected things, 1 of the followings:
1. stop or forbid users to run rebalance on the non-jmxManager locator
2. return instructive info to let users find proper way to run rebalance
3. stop or forbid a REST API for Management to run , when there is no
jmx-manager on the locator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7807) PersistentColocatedPartitionedRegionDistributedTest. testReplaceOfflineMemberAndRestart_WithMultipleDiskStores failed with a communications error
[
https://issues.apache.org/jira/browse/GEODE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt resolved GEODE-7807.
-
Fix Version/s: 1.13.0
Resolution: Resolved
This issue was caused by the commit that has since been reverted, see
https://github.com/apache/geode/pull/4726
> PersistentColocatedPartitionedRegionDistributedTest.
> testReplaceOfflineMemberAndRestart_WithMultipleDiskStores failed with a
> communications error
> -
>
> Key: GEODE-7807
> URL: https://issues.apache.org/jira/browse/GEODE-7807
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
>
> This test failed with a suspect string showing a possible message
> transmission problem. Is this possibly related to work done in early 2020 on
> BufferPool? See this revision:
> 418d929e3e03185cd6330c828c9b9ed395a76d4b
> {noformat}
> [fatal 2020/02/19 02:50:04.862 GMT
> tid=8410] While pushing message
> path='/__PR/_B__region2_1'; sender=172.17.0.4(185):41003;
> keysOnly=false; processorId=40462; waitForInit=false;
> checkTombstoneVersions=true;
> versionVector=RegionVersionVector[2ab5849689d446bd-a7da0400b0e718f7={rv0
> gc0 localVersion=0 local exceptions=[]} others={}, gc={}]; unfinished
> keys=[])> to recipients: <172.17.0.4(179):41002>
> java.lang.IllegalArgumentException: newPosition > limit: (32768 > 90)
> at
> java.base/java.nio.Buffer.createPositionException(Buffer.java:318)
> at java.base/java.nio.Buffer.position(Buffer.java:293)
> at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1086)
> at
> java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:226)
> at
> java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:67)
> at
> java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:116)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:58)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
> at
> java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:463)
> at
> org.apache.geode.internal.tcp.Connection.writeFully(Connection.java:2587)
> at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:1867)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:324)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2060)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1987)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2024)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1084)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1222)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
> at
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:259)
> at
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:983)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:785)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:460)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:319)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2896)
> at
>
[jira] [Closed] (GEODE-7807) PersistentColocatedPartitionedRegionDistributedTest. testReplaceOfflineMemberAndRestart_WithMultipleDiskStores failed with a communications error
[
https://issues.apache.org/jira/browse/GEODE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt closed GEODE-7807.
---
> PersistentColocatedPartitionedRegionDistributedTest.
> testReplaceOfflineMemberAndRestart_WithMultipleDiskStores failed with a
> communications error
> -
>
> Key: GEODE-7807
> URL: https://issues.apache.org/jira/browse/GEODE-7807
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
>
> This test failed with a suspect string showing a possible message
> transmission problem. Is this possibly related to work done in early 2020 on
> BufferPool? See this revision:
> 418d929e3e03185cd6330c828c9b9ed395a76d4b
> {noformat}
> [fatal 2020/02/19 02:50:04.862 GMT
> tid=8410] While pushing message
> path='/__PR/_B__region2_1'; sender=172.17.0.4(185):41003;
> keysOnly=false; processorId=40462; waitForInit=false;
> checkTombstoneVersions=true;
> versionVector=RegionVersionVector[2ab5849689d446bd-a7da0400b0e718f7={rv0
> gc0 localVersion=0 local exceptions=[]} others={}, gc={}]; unfinished
> keys=[])> to recipients: <172.17.0.4(179):41002>
> java.lang.IllegalArgumentException: newPosition > limit: (32768 > 90)
> at
> java.base/java.nio.Buffer.createPositionException(Buffer.java:318)
> at java.base/java.nio.Buffer.position(Buffer.java:293)
> at java.base/java.nio.ByteBuffer.position(ByteBuffer.java:1086)
> at
> java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:226)
> at
> java.base/java.nio.MappedByteBuffer.position(MappedByteBuffer.java:67)
> at
> java.base/sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:116)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:58)
> at java.base/sun.nio.ch.IOUtil.write(IOUtil.java:50)
> at
> java.base/sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:463)
> at
> org.apache.geode.internal.tcp.Connection.writeFully(Connection.java:2587)
> at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:1867)
> at
> org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:324)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:249)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:248)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:604)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2060)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1987)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2024)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1084)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1222)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1082)
> at
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:259)
> at
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:983)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:785)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:460)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:319)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2896)
> at
> org.apache.geode.internal.cache.partitioned.ManageBackupBucketMessage.operateOnPartitionedRegion(ManageBackupBucketMessage.java:159)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at
>
[jira] [Commented] (GEODE-6532) Convert compile dependencies to implementation/api dependencies
[
https://issues.apache.org/jira/browse/GEODE-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047052#comment-17047052
]
ASF subversion and git services commented on GEODE-6532:
Commit 6add39598aa6dbf1180d2d77acf807715db56e43 in geode-examples's branch
refs/heads/develop from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=6add395 ]
GEODE-6532: Dependency changes to examples related to the Geode fix. (#92)
Several transitive dependencies will be marked 'runtime' not 'compile'
in the POM from geode, causing examples to not miss symbols. Declare
those dependencies outright.
(cherry picked from commit e974408674428770c35be3b444e022d2b9f1973e)
> Convert compile dependencies to implementation/api dependencies
> ---
>
> Key: GEODE-6532
> URL: https://issues.apache.org/jira/browse/GEODE-6532
> Project: Geode
> Issue Type: Improvement
> Components: build, docs
>Reporter: Patrick Rhomberg
>Assignee: Dan Smith
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
> The {{compile}} configuration has been deprecated for some time. {{api}}
> will behave similarly, whereas {{implementation}} will appear to be a
> {{runtime}} dependency to consumers.
> This will require examining our public API so that we may correctly declare
> which dependencies are {{api}}. When a PR is made, an email should be sent
> to the dev@ and/or user@ lists warning that those consuming internal APIs
> (against best practice) may experience breakages if their own dependencies
> are not properly declared. Similarly, a release note on this topic could be
> helpful to those upgrading.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7825) can see exception info when I try to run rebalance by REST API
Gang Yan created GEODE-7825:
---
Summary: can see exception info when I try to run rebalance by
REST API
Key: GEODE-7825
URL: https://issues.apache.org/jira/browse/GEODE-7825
Project: Geode
Issue Type: Bug
Components: management, rest (admin)
Reporter: Gang Yan
as a user, when I try to run rebalance by [POST]
"http://127.0.0.1:7070/management/v1/operations/rebalances;
, sometimes can get the following response:
{code:java}
{
"statusCode": "ACCEPTED",
"statusMessage": "Operation started. Use the URI to check its status.",
"links": {
"self":
"http://127.0.0.1:7070/management/v1/operations/rebalances/7c39a7f0-6b7e-4177-9269-bfa7ce42808d;,
"list": "http://127.0.0.1:7070/management/v1/operations/rebalances;
},
"operationStart": "2020-02-27T22:48:49.716Z",
"operationEnd": "2020-02-27T22:48:49.729Z",
"operationId": "7c39a7f0-6b7e-4177-9269-bfa7ce42808d",
"operation": {
"simulate": false
},
"throwable": {
"stackTrace": [
{
"methodName": "getMemberRegionList",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 208,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "executeRebalanceOnDS",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 326,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "perform",
"fileName": "RebalanceOperationPerformer.java",
"lineNumber": 91,
"className":
"org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
"nativeMethod": false
},
{
"methodName": "lambda$submit$0",
"fileName": "OperationManager.java",
"lineNumber": 67,
"className":
"org.apache.geode.management.internal.operation.OperationManager",
"nativeMethod": false
},
{
"methodName": "run",
"fileName": "CompletableFuture.java",
"lineNumber": 1590,
"className":
"java.util.concurrent.CompletableFuture$AsyncSupply",
"nativeMethod": false
},
{
"methodName": "run",
"fileName": "Thread.java",
"lineNumber": 748,
"className": "java.lang.Thread",
"nativeMethod": false
}
]
}
}
{code}
if a post request of a-sync operation , as rebalance , is posted, the user
wants to see whether it is accepted or not. When the user want to know detail
info, he just needs to run
[GET]
http://127.0.0.1:7070/management/experimental/operations/rebalances/[operationID]
to get more information.
expected result: just show accepted or not, without throwable info
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7824) Revert Public API change to ClientRegionFactory
[
https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047030#comment-17047030
]
Lynn Hughes-Godfrey commented on GEODE-7824:
commit a2ac820116c7a54dcbf95dbaa0fd37eb5e7e09d8
Author: Kirk Lund
Date: Fri Feb 7 11:58:57 2020 -0800
GEODE-5595: Fix DeltaPropagationDUnitTest flakiness (#4653)
Improve testability of CacheClientProxy
* Extract inner classes
* Introduce CacheClientProxyFactory with support for property injection
diff --git
a/geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
b/geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
index 64256e8f8e..920deba055 100644
---
a/geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
+++
b/geode-core/src/main/java/org/apache/geode/cache/client/internal/ClientRegionFactoryImpl.java
@@ -186,8 +186,9 @@ public class ClientRegionFactoryImpl implements
ClientRegionFactory
}
@Override
- public void setConcurrencyChecksEnabled(boolean concurrencyChecksEnabled) {
+ public ClientRegionFactory setConcurrencyChecksEnabled(boolean
concurrencyChecksEnabled) {
this.attrsFactory.setConcurrencyChecksEnabled(concurrencyChecksEnabled);
+return this;
}
> Revert Public API change to ClientRegionFactory
> ---
>
> Key: GEODE-7824
> URL: https://issues.apache.org/jira/browse/GEODE-7824
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Udo Kohlmeyer
>Assignee: Kirk Lund
>Priority: Major
>
> As per a commit to the ClientRegionFactory, the public API was changed.
> Even though it was to get some consistency in the class, it does now deviate
> from the released public API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7824) Revert Public API change to ClientRegionFactory
[ https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-7824: --- Assignee: Kirk Lund > Revert Public API change to ClientRegionFactory > --- > > Key: GEODE-7824 > URL: https://issues.apache.org/jira/browse/GEODE-7824 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.13.0 >Reporter: Udo Kohlmeyer >Assignee: Kirk Lund >Priority: Major > > As per a commit to the ClientRegionFactory, the public API was changed. > Even though it was to get some consistency in the class, it does now deviate > from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7824) Revert Public API change to ClientRegionFactory
[ https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047027#comment-17047027 ] Owen Nichols commented on GEODE-7824: - While this change is source-compatible, it is not binary compatible, according to [https://stackoverflow.com/questions/47476509/can-i-change-a-return-type-to-be-a-strict-subtype-and-retain-binary-compatibilit] > Revert Public API change to ClientRegionFactory > --- > > Key: GEODE-7824 > URL: https://issues.apache.org/jira/browse/GEODE-7824 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.13.0 >Reporter: Udo Kohlmeyer >Priority: Major > > As per a commit to the ClientRegionFactory, the public API was changed. > Even though it was to get some consistency in the class, it does now deviate > from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7824) Revert Public API change to ClientRegionFactory
[
https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047026#comment-17047026
]
Owen Nichols commented on GEODE-7824:
-
There's been only 1 recent change to this file:
Geode 1.12 and earlier API:
{code:java}
void setConcurrencyChecksEnabled(boolean concurrencyChecksEnabled);
{code}
What's on develop (1.13) now:
{code:java}
ClientRegionFactory setConcurrencyChecksEnabled(boolean
concurrencyChecksEnabled);
{code}
> Revert Public API change to ClientRegionFactory
> ---
>
> Key: GEODE-7824
> URL: https://issues.apache.org/jira/browse/GEODE-7824
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> As per a commit to the ClientRegionFactory, the public API was changed.
> Even though it was to get some consistency in the class, it does now deviate
> from the released public API.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7824) Revert Public API change to ClientRegionFactory
[ https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047023#comment-17047023 ] Anthony Baker commented on GEODE-7824: -- [~ukohlmeyer] what is the API that changed? > Revert Public API change to ClientRegionFactory > --- > > Key: GEODE-7824 > URL: https://issues.apache.org/jira/browse/GEODE-7824 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.13.0 >Reporter: Udo Kohlmeyer >Priority: Major > > As per a commit to the ClientRegionFactory, the public API was changed. > Even though it was to get some consistency in the class, it does now deviate > from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7824) Revert Public API change to ClientRegionFactory
[ https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7824: - Component/s: regions > Revert Public API change to ClientRegionFactory > --- > > Key: GEODE-7824 > URL: https://issues.apache.org/jira/browse/GEODE-7824 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.13.0 >Reporter: Udo Kohlmeyer >Priority: Major > > As per a commit to the ClientRegionFactory, the public API was changed. > Even though it was to get some consistency in the class, it does now deviate > from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7824) Revert Public API change to ClientRegionFactory
Udo Kohlmeyer created GEODE-7824: Summary: Revert Public API change to ClientRegionFactory Key: GEODE-7824 URL: https://issues.apache.org/jira/browse/GEODE-7824 Project: Geode Issue Type: Bug Reporter: Udo Kohlmeyer As per a commit to the ClientRegionFactory, the public API was changed. Even though it was to get some consistency in the class, it does now deviate from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7824) Revert Public API change to ClientRegionFactory
[ https://issues.apache.org/jira/browse/GEODE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7824: - Affects Version/s: 1.13.0 > Revert Public API change to ClientRegionFactory > --- > > Key: GEODE-7824 > URL: https://issues.apache.org/jira/browse/GEODE-7824 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Udo Kohlmeyer >Priority: Major > > As per a commit to the ClientRegionFactory, the public API was changed. > Even though it was to get some consistency in the class, it does now deviate > from the released public API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-7823.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17047014#comment-17047014
]
ASF subversion and git services commented on GEODE-7823:
Commit 088e68242df3e4acc6d661d636f5a786e6b5d6b1 in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=088e682 ]
GEODE-7823: eliminate org.junit unavailable compile error in IntelliJ (#4742)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-7823:
---
Assignee: Bill Burcham
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-7823:
Affects Version/s: 1.13.0
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.13.0
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046946#comment-17046946
]
ASF subversion and git services commented on GEODE-7814:
Commit 5a325f4fe59b6203ef93801ee185d2fb79a8f4c8 in geode's branch
refs/heads/release/1.12.0 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5a325f4 ]
GEODE-7814: Avoid Messaging Unnecessary Allocations (#4731)
Avoid unnecessary object allocations by making the attributes static.
(cherry picked from commit db86faec699aca67c02325bca22dcd5b913ddfed)
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7823) compile error "package org.junit does not exist" when running "geode-core:compileJmhJava" Gradle task in IntelliJ
[
https://issues.apache.org/jira/browse/GEODE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-7823:
Summary: compile error "package org.junit does not exist" when running
"geode-core:compileJmhJava" Gradle task in IntelliJ (was: compile error
"package org.junit does not exist" when building geode-core in IntelliJ)
> compile error "package org.junit does not exist" when running
> "geode-core:compileJmhJava" Gradle task in IntelliJ
> -
>
> Key: GEODE-7823
> URL: https://issues.apache.org/jira/browse/GEODE-7823
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Bill Burcham
>Priority: Major
>
> When building the project in IntelliJ, I see this compile error:
> {code}
> …RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
> import static org.junit.Assert.assertEquals;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-7814:
Fix Version/s: 1.12.0
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.12.0, 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7823) compile error "package org.junit does not exist" when building geode-core in IntelliJ
Bill Burcham created GEODE-7823:
---
Summary: compile error "package org.junit does not exist" when
building geode-core in IntelliJ
Key: GEODE-7823
URL: https://issues.apache.org/jira/browse/GEODE-7823
Project: Geode
Issue Type: Bug
Components: build
Reporter: Bill Burcham
When building the project in IntelliJ, I see this compile error:
{code}
…RangeQueryWithIndexBenchmark.java:17: error: package org.junit does not exist
import static org.junit.Assert.assertEquals;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
[
https://issues.apache.org/jira/browse/GEODE-7822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-7822:
---
Labels: flaky (was: )
> MemoryThresholdsOffHeapDUnitTest has failures
> -
>
> Key: GEODE-7822
> URL: https://issues.apache.org/jira/browse/GEODE-7822
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Labels: flaky
>
> These two failures were seen in mass test runs...
> {noformat}
> testPRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testPRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
> VM 2 running on Host a57bd8581b8d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
> {noformat}
> testDRLoadRejection
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
> {noformat}
> {noformat}
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
> testDRLoadRejection FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
> VM 2 running on Host b2c673017cde with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
> Caused by:
>java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at
> org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7822) MemoryThresholdsOffHeapDUnitTest has failures
Mark Hanson created GEODE-7822:
--
Summary: MemoryThresholdsOffHeapDUnitTest has failures
Key: GEODE-7822
URL: https://issues.apache.org/jira/browse/GEODE-7822
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Mark Hanson
These two failures were seen in mass test runs...
{noformat}
testPRLoadRejection
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/674
{noformat}
{noformat}
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
testPRLoadRejection FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call in
VM 2 running on Host a57bd8581b8d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1045)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertFalse(Assert.java:64)
at org.junit.Assert.assertFalse(Assert.java:74)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$31.call(MemoryThresholdsOffHeapDUnitTest.java:1077){noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582515952/]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
[http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582515952/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz]
{noformat}
testDRLoadRejection
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/742
{noformat}
{noformat}
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest >
testDRLoadRejection FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call in
VM 2 running on Host b2c673017cde with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:462)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest.testDRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:667)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertFalse(Assert.java:64)
at org.junit.Assert.assertFalse(Assert.java:74)
at
org.apache.geode.cache.management.MemoryThresholdsOffHeapDUnitTest$18.call(MemoryThresholdsOffHeapDUnitTest.java:673)
{noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-results/distributedTest/1582626992/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-mass-test-run-main/1.12.0-SNAPSHOT.0005/test-artifacts/1582626992/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0005.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7460) CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs Failure
[
https://issues.apache.org/jira/browse/GEODE-7460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046909#comment-17046909
]
Mark Hanson commented on GEODE-7460:
More mass test run failures.
{noformat}
testGroupsInAllVMs
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/667
testGroupsInAllVMs
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/633
testGroupsInAllVMs
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/604
{noformat}
> CI failure: DistributedMemberDUnitTest.testGroupsInAllVMs Failure
> -
>
> Key: GEODE-7460
> URL: https://issues.apache.org/jira/browse/GEODE-7460
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Robert Houghton
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.12.0
>
>
> From the failing job:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-results/distributedTest/1573784422/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-artifacts/1573784422/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0016.tgz
> DistributedTest failure due to exception:
> org.apache.geode.distributed.DistributedMemberDUnitTest > testGroupsInAllVMs
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run in VM 0 running
> on Host 3e09f1029b44 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.distributed.DistributedMemberDUnitTest.testGroupsInAllVMs(DistributedMemberDUnitTest.java:333)
> Caused by:
> org.apache.geode.SystemConnectException: One or more peers generated
> exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1625)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:759)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:136)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3009)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:269)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:181)
> at
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run(DistributedMemberDUnitTest.java:339)
> Caused by:
>
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> DistributedSystem is shutting down, caused by
> org.apache.geode.ForcedDisconnectException: Exiting due to possible network
> partition event due to loss of 1 cache processes:
> [172.17.0.14(myName:1):41001]
> at
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1591)
> at
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.send(GMSMembershipManager.java:1751)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1985)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1622)
> ... 8 more
> Caused by:
> org.apache.geode.ForcedDisconnectException: Exiting due to
> possible network
[jira] [Commented] (GEODE-4194) DiskDistributedNoAckAsyncOverflowRegionDUnitTest testNBRegionDestructionDuringGetInitialImage hangs
[
https://issues.apache.org/jira/browse/GEODE-4194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046905#comment-17046905
]
Mark Hanson commented on GEODE-4194:
More failures in mass-test-runs
{noformat}
testNBRegionInvalidationDuringGetInitialImage_OFF_HEAP_DISTRIBUTED_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/691
testNBRegionInvalidationDuringGetInitialImage_OFF_HEAP_GLOBAL_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/603
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/688
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/622
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/615
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/614
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/602
testNBRegionInvalidationDuringGetInitialImage_OFF_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/681
testNBRegionInvalidationDuringGetInitialImage_OFF_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/651
testNBRegionInvalidationDuringGetInitialImage_OFF_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/640
testNBRegionInvalidationDuringGetInitialImage_HEAP_GLOBAL_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/603
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/676
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/656
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_NO_ACK_CCE
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/632
{noformat}
> DiskDistributedNoAckAsyncOverflowRegionDUnitTest
> testNBRegionDestructionDuringGetInitialImage hangs
> ---
>
> Key: GEODE-4194
> URL: https://issues.apache.org/jira/browse/GEODE-4194
> Project: Geode
> Issue Type: Bug
> Components: extensions
>Reporter: Lynn Gallinat
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
>
> This test caused concourse to timeout when it hung:
> Started @ 2018-01-03 18:49:16.700 +
> 2018-01-03 19:21:00.165 +
> org.apache.geode.cache30.DiskDistributedNoAckAsyncOverflowRegionDUnitTest
> testNBRegionDestructionDuringGetInitialImage
> Ended @ 2018-01-03 20:55:26.951 +
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) JMXMBeanReconnectDUnitTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046902#comment-17046902
]
Mark Hanson commented on GEODE-7710:
More failures in the mass test runs
{noformat}
serverMXBeansOnServerAreUnaffectedByLocatorCrash
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/711
locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/695
serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/704
serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/689
serverMXBeansAreRestoredOnBothLocatorsAfterCrashedServerReturns
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/661
locatorHasMemberTypeMXBeansForBothLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/728
locatorHasMemberTypeMXBeansForBothLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/657
locatorHasMemberTypeMXBeansForBothLocators
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/618
{noformat}
> JMXMBeanReconnectDUnitTest fails intermittently because one locator is
> missing the LockServiceMXBean
>
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7815) Document setting a GEODE_HOME env variable
[ https://issues.apache.org/jira/browse/GEODE-7815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046886#comment-17046886 ] ASF subversion and git services commented on GEODE-7815: Commit 8498329c10f66d8aeca01eefc9c3abf646fe8d2c in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8498329 ] GEODE-7815: Document setting a GEODE_HOME env variable (#4732) > Document setting a GEODE_HOME env variable > -- > > Key: GEODE-7815 > URL: https://issues.apache.org/jira/browse/GEODE-7815 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > While internal methods will check the classpath for locating WAR files, we > should document that setting a GEODE_HOME environment variable might an > easier method for some installations than changing the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7664) CI Failure: ClientClusterManagementServiceDUnitTest > deleteRegionOnSpecificGroup
[
https://issues.apache.org/jira/browse/GEODE-7664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046838#comment-17046838
]
Juan Ramos commented on GEODE-7664:
---
This happened again while running the CI for an unrelated PR:
https://concourse.apachegeode-ci.info/builds/135718.
> CI Failure: ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup
> -
>
> Key: GEODE-7664
> URL: https://issues.apache.org/jira/browse/GEODE-7664
> Project: Geode
> Issue Type: Bug
>Reporter: Ivan Godwin
>Assignee: Jinmei Liao
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1454]
>
> {code:java}
> org.apache.geode.management.client.ClientClusterManagementServiceDUnitTest >
> deleteRegionOnSpecificGroup FAILEDjava.lang.AssertionError: Suspicious
> strings were written to the log during this run.Fix the strings or use
> IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1874 [error 2020/01/09 18:52:37.224 GMT
> tid=353]
> org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> org.apache.geode.cache.RegionDestroyedException:org.apache.geode.internal.cache.DistributedRegion[path='/region2';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
> concurrencyChecksEnabled]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7296)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2750)
> at
> org.apache.geode.internal.cache.LocalRegion.size(LocalRegion.java:8256)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:307)
> at
> org.apache.geode.management.internal.configuration.realizers.RegionConfigRealizer.get(RegionConfigRealizer.java:48)
>
> at
> org.apache.geode.management.internal.configuration.realizers.ConfigurationRealizer.exists(ConfigurationRealizer.java:35)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.executeUpdate(CacheRealizationFunction.java:130)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:79)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:394)
>
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:458)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:449)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED
[ https://issues.apache.org/jira/browse/GEODE-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-7821: -- Priority: Minor (was: Major) > DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > - > > Key: GEODE-7821 > URL: https://issues.apache.org/jira/browse/GEODE-7821 > Project: Geode > Issue Type: Bug > Components: core, tests >Reporter: Joris Melchior >Priority: Minor > Fix For: 1.13.0 > > > Seen this fail in a couple of places. Failures do not seem to have a direct > relation to the pull request for the job. > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581 > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION > FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run > in VM 2 running on Host 8f4bff2410d5 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:437) > at > org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414) > Caused by: > org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, > 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
[jira] [Created] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED
Joris Melchior created GEODE-7821: - Summary: DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED Key: GEODE-7821 URL: https://issues.apache.org/jira/browse/GEODE-7821 Project: Geode Issue Type: Bug Components: core, tests Reporter: Joris Melchior Fix For: 1.13.0 Seen this fail in a couple of places. Failures do not seem to have a direct relation to the pull request for the job. https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581 org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run in VM 2 running on Host 8f4bff2410d5 with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) at org.apache.geode.test.dunit.VM.invoke(VM.java:437) at org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414) Caused by: org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66,
[jira] [Commented] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[ https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046763#comment-17046763 ] Joris Melchior commented on GEODE-6284: --- Additional failure: [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/1558] org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated > test[from_v1.9.2, with reindex=false, singleHopEnabled=true] FAILED java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in log4j at line 9011 /home/geode/.gradle/caches/modules-2/files-2.1/com.google.guava/failureaccess/1.0.1/1dcf1de382a0bf95a3d8b0849546c8[info 2020/02/27 07:25:56.286 GMT tid=80] Communication with locator /172.17.0.37:24573 failed with java.io.EOFException: Locator at /172.17.0.37:24573 did not respond. This is normal if the locator was shutdown. If it wasn't check its log for exceptions.. java.io.EOFException: Locator at /172.17.0.37:24573 did not respond. This is normal if the locator was shutdown. If it wasn't check its log for exceptions. at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500) at org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276) 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) Caused by: java.io.EOFException at java.io.DataInputStream.readByte(DataInputStream.java:267) at org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775) at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978) at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227) ... 11 more org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver > luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver[from_v1.9.0, with reindex=true, singleHopEnabled=true] FAILED java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in log4j at line 8587 /home/geode/.gradle/caches/modules-2/files-2.1/com.google.guava/failureaccess/1.0.1/1dcf1de382a0bf95a3d8b0849546c8[info 2020/02/27 07:26:07.784 GMT tid=51] Communication with locator /172.17.0.12:25434 failed with java.io.EOFException: Locator at /172.17.0.12:25434 did not respond. This is normal if the locator was shutdown. If it wasn't check its log for exceptions.. java.io.EOFException: Locator at /172.17.0.12:25434 did not respond. This is normal if the locator was shutdown. If it wasn't check its log for exceptions. at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287) at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500) at org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371) at
[jira] [Updated] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7820:
--
Attachment: Screenshot 2020-02-27 at 12.59.23.png
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: Screenshot 2020-02-27 at 12.59.23.png, setRecipients.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046595#comment-17046595
]
Juan Ramos commented on GEODE-7820:
---
Attaching the results of the same test after applying the PR changes to the
{{develop}} branch and comparing the snapshot with the original one (Geode
1.10). !Screenshot 2020-02-27 at 12.59.23.png!
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: Screenshot 2020-02-27 at 12.59.23.png, setRecipients.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos reassigned GEODE-7820:
-
Assignee: Juan Ramos
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Attachments: setRecipients.png
>
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7820) Avoid Unnecessary toArray Invocations
Juan Ramos created GEODE-7820:
-
Summary: Avoid Unnecessary toArray Invocations
Key: GEODE-7820
URL: https://issues.apache.org/jira/browse/GEODE-7820
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Juan Ramos
Attachments: setRecipients.png
The {{DistributionMessage}} class receives the recipients as a {{Collection}}
object (which is always a {{Set}} after inspecting the calls) but it internally
transforms the collection into an array {{[]}}, this transformation appears to
be useless as we end up converting the array {{[]}} into a {{List}} across
several parts of the code afterwards when we need to do something with it.
Using one of our internal testing scenarios and a java profiler we detected
that, under the current develop {{branch}}, we spend ~8 seconds more than when
using Geode 1.10 just by executing this {{toArray}} transformation (screenshot
attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7820:
--
Labels: GeodeCommons (was: )
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: setRecipients.png
>
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7820) Avoid Unnecessary toArray Invocations
[
https://issues.apache.org/jira/browse/GEODE-7820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7820:
--
Attachment: setRecipients.png
> Avoid Unnecessary toArray Invocations
> -
>
> Key: GEODE-7820
> URL: https://issues.apache.org/jira/browse/GEODE-7820
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Priority: Major
> Attachments: setRecipients.png
>
>
> The {{DistributionMessage}} class receives the recipients as a {{Collection}}
> object (which is always a {{Set}} after inspecting the calls) but it
> internally transforms the collection into an array {{[]}}, this
> transformation appears to be useless as we end up converting the array {{[]}}
> into a {{List}} across several parts of the code afterwards when we need to
> do something with it.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current develop {{branch}}, we spend ~8 seconds more than
> when using Geode 1.10 just by executing this {{toArray}} transformation
> (screenshot attached), which can be completely avoided.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-7814:
--
Description:
The {{DistributionMessage}} class unnecessary allocates instances of
{{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
These attributes are {{final}} and only used to execute internal comparisons
but, since they are not declared as {{static}}, every instance of
{{DistributionMessage}} will have its own instance, generating unnecessary
garbage.
Using one of our internal testing scenarios and a java profiler we detected
that, under the current {{develop}} branch, we create 14.824 and 11.212 more
instances of {{java.util.Collection$SingletonList}} and
{{InternalDistributedMember[]}} than when using Geode 1.10.
The increase in the memory footprint is not much (around 1MB all together),
and the time spent on this operation is around 1.5 seconds slower overall
(screenshots attached).
was:
The {{DistributionMessage}} class unnecessary allocates instances of
{{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
These attributes are {{final}} and only used to execute internal comparisons
but, since they are not declared as {{static}}, every instance of
{{DistributionMessage}} will have its own instance, generating unnecessary
garbage.
Using one of our internal testing scenarios and a java profiler we detected
that we create 0 instances of {{java.util.Collection$SingletonList}} and
{{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
respectively when using the latest {{develop}} branch.
The increase in the memory footprint is not much (around 1MB all together), and
the time spent on this operation is around 1.5 seconds slower overall
(screenshots attached).
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that, under the current {{develop}} branch, we create 14.824 and 11.212 more
> instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} than when using Geode 1.10.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos resolved GEODE-7814.
---
Fix Version/s: 1.13.0
Resolution: Fixed
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.13.0
>
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7814) Unnecessary Object Allocations in DistributionMessage
[
https://issues.apache.org/jira/browse/GEODE-7814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046415#comment-17046415
]
ASF subversion and git services commented on GEODE-7814:
Commit db86faec699aca67c02325bca22dcd5b913ddfed in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=db86fae ]
GEODE-7814: Avoid Messaging Unnecessary Allocations (#4731)
Avoid unnecessary object allocations by making the attributes static.
> Unnecessary Object Allocations in DistributionMessage
> -
>
> Key: GEODE-7814
> URL: https://issues.apache.org/jira/browse/GEODE-7814
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Attachments: countDifference.png, timeSpent.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The {{DistributionMessage}} class unnecessary allocates instances of
> {{java.util.Collection$SingletonList}} and {{InternalDistributedMember[]}}
> through the attributes {{EMPTY_RECIPIENTS_ARRAY}} and {{ALL_RECIPIENTS_LIST}}.
> These attributes are {{final}} and only used to execute internal comparisons
> but, since they are not declared as {{static}}, every instance of
> {{DistributionMessage}} will have its own instance, generating unnecessary
> garbage.
> Using one of our internal testing scenarios and a java profiler we detected
> that we create 0 instances of {{java.util.Collection$SingletonList}} and
> {{InternalDistributedMember[]}} using Geode 1.10, but 14.824 and 11.212
> respectively when using the latest {{develop}} branch.
> The increase in the memory footprint is not much (around 1MB all together),
> and the time spent on this operation is around 1.5 seconds slower overall
> (screenshots attached).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
