date:20210527

2021-05-27 Thread ASF subversion and git services (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9299:
--
Labels: pull-request-available  (was: )

> CI Failure: 
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > 
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
>  > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2] 
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here: 
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover

2021-05-27 Thread Barrett Oglesby (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352894#comment-17352894
 ] 

Barrett Oglesby commented on GEODE-9299:


If I simulate this behavior with a sleep on key=5 in Put65, I see the same 
extra event in the queue.

Keys 0-4 are processed normally in servers 1 and 2:

Server 1:
{noformat}
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=0
ServerConnection on port 57561 Thread 1: 
ParallelGatewaySenderEventProcessor.enqueueEvent put dataKey=0; shadowKey=113
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=1
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=8 dom #2 port=57607: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=1; shadowKey=114
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=2
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=8 dom #2 port=57607: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=2; shadowKey=115
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=3
ServerConnection on port 57561 Thread 1: 
ParallelGatewaySenderEventProcessor.enqueueEvent put dataKey=3; shadowKey=116
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=4
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=8 dom #2 port=57607: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=4; shadowKey=117
{noformat}
Server 2:
{noformat}
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=8 dom #1 port=57606: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=0; shadowKey=113
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=8 dom #1 port=57606: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=1; shadowKey=114
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=8 dom #1 port=57606: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=2; shadowKey=115
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=8 dom #1 port=57606: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=3; shadowKey=116
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=8 dom #1 port=57606: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=4; shadowKey=117
{noformat}
The ServerConnection thread in server 1 sleeps before processing key=5:
{noformat}
ServerConnection on port 57561 Thread 1: Put65.cmdExecute processing key=5
ServerConnection on port 57561 Thread 1: Put65.cmdExecute sleeping key=5
{noformat}
The client times out and fails over to server2 and retries key=5 and continues 
with keys 6-9. Notice the event with key=5 has shadowKey=118. Thats the key in 
the queue.
{noformat}
ServerConnection on port 57587 Thread 2: Put65.cmdExecute processing retried 
key=5
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=10 dom #2 port=57668: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=5; shadowKey=118
ServerConnection on port 57587 Thread 2: Put65.cmdExecute processing key=6
ServerConnection on port 57587 Thread 2: 
ParallelGatewaySenderEventProcessor.enqueueEvent put dataKey=6; shadowKey=119
ServerConnection on port 57587 Thread 2: Put65.cmdExecute processing key=7
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=10 dom #2 port=57668: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=7; shadowKey=120
ServerConnection on port 57587 Thread 2: Put65.cmdExecute processing key=8
ServerConnection on port 57587 Thread 2: 
ParallelGatewaySenderEventProcessor.enqueueEvent put dataKey=8; shadowKey=121
ServerConnection on port 57587 Thread 2: Put65.cmdExecute processing key=9
P2P message reader for 10.166.145.22(ln-1:85023):41002 unshared ordered 
uid=10 dom #2 port=57668: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=9; shadowKey=122
{noformat}
Server 1 enqueues keys 5-9:
{noformat}
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=10 dom #1 port=57664: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=5; shadowKey=118
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=10 dom #1 port=57664: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=6; shadowKey=119
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=10 dom #1 port=57664: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=7; shadowKey=120
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=10 dom #1 port=57664: ParallelGatewaySenderEventProcessor.enqueueEvent put 
dataKey=8; shadowKey=121
P2P message reader for 10.166.145.22(ln-2:85040):41003 unshared ordered 
uid=10 dom #1 port=57664: ParallelGatewaySenderEventProcessor.enqueueEvent put

[jira] [Commented] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover

2021-05-27 Thread Barrett Oglesby (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352893#comment-17352893
 ] 

Barrett Oglesby commented on GEODE-9299:


The failing assertion is verifying the number of entries in the local secondary 
queues is 100 (which matches the number of puts). Instead, it is 101.
{noformat}
int localServer1QueueSize = localServer1.invoke(() -> 
getQueueRegionSize(senderId, false));
int localServer2QueueSize = localServer2.invoke(() -> 
getQueueRegionSize(senderId, false));
assertEquals(numPuts, localServer1QueueSize + localServer2QueueSize);
{noformat}
Here is some logging that shows the behavior in this test.

Client Starts:
{noformat}
[vm3_v1.12.2] [info 2021/05/21 21:12:16.982 GMT   tid=0x22] Received method: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$146/0x0001008afc40.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$146/0x0001008afc40@59079e6c
[vm3_v1.12.2] [info 2021/05/21 21:12:17.599 GMT   tid=0x22] Using 
org.apache.geode.logging.log4j.internal.impl.Log4jLoggingProvider from 
ServiceLoader for service org.apache.geode.logging.internal.spi.LoggingProvider
[vm3_v1.12.2] [info 2021/05/21 21:12:24.490 GMT   
tid=0x32] Updating membership port.  Port changed from 0 to 46166.  ID is now 
7e72072330df(13685:loner):0:6094c590
[vm3_v1.12.2] [info 2021/05/21 21:12:24.526 GMT   tid=0x22] Got result: null
[vm3_v1.12.2]  from 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$146/0x0001008afc40.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$146/0x0001008afc40@59079e6c
 (took 7538 ms)
{noformat}
Client does 100 puts in 22069ms with a SocketTimeoutException:
{noformat}
[vm3_v1.12.2] [info 2021/05/21 21:12:24.567 GMT   tid=0x22] Received method: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$339/0x000100959840.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$339/0x000100959840@2e8f97c1
[vm3_v1.12.2] [warn 2021/05/21 21:12:42.233 GMT   tid=0x22] Pool unexpected socket timed out on client 
connection=Pooled Connection to 7e72072330df:21250: 
Connection[7e72072330df:21250]@93891194)
[vm3_v1.12.2] [info 2021/05/21 21:12:46.638 GMT   tid=0x22] Got result: null
[vm3_v1.12.2]  from 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$339/0x000100959840.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$339/0x000100959840@2e8f97c1
 (took 22069 ms)
{noformat}
The SocketTimeoutException means the client retried the put. That ends up being 
2 puts for the same event.

Server 1 returns secondary queue size:
{noformat}
[vm1_v1.12.2] [info 2021/05/21 21:12:46.668 GMT   tid=0x22] Received method: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$520/0x000100ad1040.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$520/0x000100ad1040@79d1c376
[vm1_v1.12.2] [info 2021/05/21 21:12:47.598 GMT   tid=0x22] Got result: null
[vm1_v1.12.2]  from 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$520/0x000100ad1040.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$520/0x000100ad1040@79d1c376
 (took 929 ms)
{noformat}
Server 2 returns secondary queue size:
{noformat}
[vm2_v1.12.2] [info 2021/05/21 21:12:47.617 GMT   tid=0x22] Received method: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$517/0x000100ae2c40.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$517/0x000100ae2c40@751350b6
[vm2_v1.12.2] [info 2021/05/21 21:12:47.782 GMT   tid=0x22] Got result: null
[vm2_v1.12.2]  from 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$517/0x000100ae2c40.run
 with 0 args on object: 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest$$Lambda$517/0x000100ae2c40@751350b6
 (took 161 ms)
{noformat}
The assertEquals check fails right after this, and the test shuts down. 

Here is some more detail.

Server 1 buckets are created:
{noformat}
[vm1_v1.12.2] [info 2021/05/21 21:12:24.771 GMT   tid=0x39] Initializing region 
_B__testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from__v1.12.2]__region_0
[vm1_v1.12.2] [info 2021/05/21 21:12:24.847 GMT   tid=0x39] Initialization of region 
_B__testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from__v1.12.2]__region_0
 completed
[vm1_v1.12.2] [info 2021/05/21 21:12:25.418 GMT   tid=0x39] Initializing region 
_B__testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from__v1.12.2]__region_1
[vm1_v1.12.2] [info 2021/05/21 21:12:25.439 GMT   tid=0x39] Initialization of region 
_B__testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from__v1.12.2]__region_1
 completed
[vm1_v1.12.2] [info 2021/05/21 21:12:26.012

[jira] [Assigned] (GEODE-9299) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover

2021-05-27 Thread Barrett Oglesby (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barrett Oglesby reassigned GEODE-9299:
--

Assignee: Barrett Oglesby

> CI Failure: 
> WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover > 
> testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
> --
>
> Key: GEODE-9299
> URL: https://issues.apache.org/jira/browse/GEODE-9299
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Barrett Oglesby
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
>  > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.12.2] 
> FAILED
> java.lang.AssertionError: expected:<100> but was:<101>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.stopSenderAndVerifyEvents(WANRollingUpgradeDUnitTest.java:227)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:98)
> {code}
> CI Failure: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/229#B
> Artifacts Available here: 
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0253/test-results/upgradeTest/1621635640/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-8772) Make tests assign necessary ports in test JVM [PERMANENT]



[ 
https://issues.apache.org/jira/browse/GEODE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352884#comment-17352884
 ] 

ASF subversion and git services commented on GEODE-8772:


Commit b67d77a0241d03627c244951f8ce9b977b0f2fca in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b67d77a ]

GEODE-8772: Fix ClusterComms test port conflicts (#6533)

Change `ClusterCommunicationsDUnitTest` to assign the locator port in
the test JVM and to not start the HTTP service.

BACKGROUND

I am working on a project to allow Geode tests to run in parallel
outside of Docker. Running in parallel outside of Docker requires tests:
- To assign ports only in the test JVM, to ensure that ports are
  assigned only by the latest implementation of `AvailablePortHelper`,
  which knows how to allocate a unique range of ports to each test.
- Not to start services using default ports, to ensure that no two tests
  try to use a default port at the same time.

This commit prepares for those changes.

PROBLEMS

`ClusterCommunicationsDUnitTest` inhibits running in parallel outside of
Docker in two ways:

- It calls `createLocator()` in child VMs running prior versions of
  Geode. The method assigns a locator port by calling
  `AvailablePortHelper`. The old implementation of `AvailablePortHelper`
  in the child VM might assign a port that is "reserved" by another
  test, resulting in bind failures.
- `createLocator()` tacitly starts the HTTP service on the default port
  (7070). If multiple tests attempt to bind to this port, some will
  experience bind failures.

THIS COMMIT

Change `ClusterCommunicationsDUnitTest` to:

- Assign the locator port in the test JVM.
- Disable the HTTP service, which the test does not need.

> Make tests assign necessary ports in test JVM [PERMANENT]
> -
>
> Key: GEODE-8772
> URL: https://issues.apache.org/jira/browse/GEODE-8772
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> *Make tests assign all necessary ports.* Many distributed tests and upgrade 
> tests (and sometimes others) launch members with default ports, especially 
> for JMX (1099) and HTTP service (7070). When run in parallel outside of 
> docker, these tests often fail because the default port is already in use in 
> another test.
> Except when specifically testing the product's use of the defaults, every 
> test should assign ports from a pool of ports known to be available. For many 
> tests, we can accomplish this by changing the test framework to assign 
> available ports. Other tests may require changes in the test code.
> *Assign ports only in test JVMs, and not in child VMs.* The 
> {{AvailablePortHelper}} class occasionally gains new features to improve its 
> assignment of ports when tests run in parallel. For these improvements to 
> work, each test must use the latest {{AvailablePortHelper}} implementation 
> for all port assignments. Child VMs that run older versions of Geode may not 
> include the latest implementation of {{AvailablePortHelper}}. For this 
> reason, tests should invoke {{AvailablePortHelper}} only in the test JVM and 
> not in child VMs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9309) Add a tool to analyze Geode test progress files

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352881#comment-17352881
 ] 

ASF subversion and git services commented on GEODE-9309:


Commit 034d106d688bad754ad647b12949cfbfc32cf414 in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=034d106 ]

GEODE-9309: Fix progress tool duration calc (#6532)

* GEODE-9309: Fix progress tool duration calc

If a test has no end event, report its duration as 0 instead of
negative.

Authored-by: Dale Emery 

* Add copyright to new test file

> Add a tool to analyze Geode test progress files
> ---
>
> Key: GEODE-9309
> URL: https://issues.apache.org/jira/browse/GEODE-9309
> Project: Geode
>  Issue Type: Test
>  Components: tests, tools
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: pull-request-available
>
> Add a tool to filter and format information from Geode test progress files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9309) Add a tool to analyze Geode test progress files

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352882#comment-17352882
 ] 

ASF subversion and git services commented on GEODE-9309:


Commit 034d106d688bad754ad647b12949cfbfc32cf414 in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=034d106 ]

GEODE-9309: Fix progress tool duration calc (#6532)

* GEODE-9309: Fix progress tool duration calc

If a test has no end event, report its duration as 0 instead of
negative.

Authored-by: Dale Emery 

* Add copyright to new test file

> Add a tool to analyze Geode test progress files
> ---
>
> Key: GEODE-9309
> URL: https://issues.apache.org/jira/browse/GEODE-9309
> Project: Geode
>  Issue Type: Test
>  Components: tests, tools
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: pull-request-available
>
> Add a tool to filter and format information from Geode test progress files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9333) SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted may fail due to IndexOutOfBoundsException

2021-05-27 Thread Donal Evans (Jira)

Donal Evans created GEODE-9333:
--

 Summary: 
SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted 
may fail due to IndexOutOfBoundsException
 Key: GEODE-9333
 URL: https://issues.apache.org/jira/browse/GEODE-9333
 Project: Geode
  Issue Type: Bug
  Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans


Seen in a PR pre-checkin test run:
{noformat}
org.apache.geode.redis.session.SessionsAndCrashesDUnitTest > 
sessionOperationsDoNotFail_whileServersAreRestarted FAILED
java.lang.IndexOutOfBoundsException: Index -5 out of bounds for length 100
at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
at 
jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
at java.util.Objects.checkIndex(Objects.java:372)
at java.util.ArrayList.get(ArrayList.java:459)
at 
org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.validateSessionAttributes(SessionsAndCrashesDUnitTest.java:179)
at 
org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:170)
{noformat}
This occurs in the below block when {{totalUpdates}} is less than 
{{NUM_SESSIONS}}.
{code:java}
for (int i = totalUpdates - NUM_SESSIONS; i < totalUpdates; i++) {
  int sessionIdx = i % NUM_SESSIONS;
  String sessionId = sessionIds.get(sessionIdx);
...
{code}
Running the test locally with some trace logging added, it seems that 
{{totalUpdates}} is typically ~120, so if something were to cause updates to be 
20% slower on a run of the test, this failure could show up. A solution might 
be to either await until at least {{NUM_SESSIONS}} updates have been performed 
by the updater threads, or to put in some logic to handle the case when 
{{totalUpdates}} is less than {{NUM_SESSIONS}}. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9332) CI Failure: JmxServerReconnectDistributedTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash



[ 
https://issues.apache.org/jira/browse/GEODE-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352878#comment-17352878
 ] 

Geode Integration commented on GEODE-9332:
--

Seen in [DistributedTestOpenJDK11 
#256|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/256]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0270/test-results/distributedTest/1622150094/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0270/test-artifacts/1622150094/distributedtestfiles-OpenJDK11-1.15.0-build.0270.tgz].

> CI Failure: JmxServerReconnectDistributedTest > 
> serverMXBeansOnServerAreUnaffectedByLocatorCrash
> 
>
> Key: GEODE-9332
> URL: https://issues.apache.org/jira/browse/GEODE-9332
> Project: Geode
>  Issue Type: Test
>  Components: jmx, tests
>Reporter: Owen Nichols
>Priority: Major
>
> {noformat}
> java.lang.AssertionError: [GemFire mxbeans on locator2] 
> Expecting HashSet:
>   [GemFire:type=Member,member=locator1,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> GemFire:service=Region,name=/region,type=Member,member=server,
> GemFire:service=Manager,type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator2,
> GemFire:type=Member,member=locator2,
> GemFire:type=Member,member=server,
> GemFire:service=FileUploader,type=Distributed,
> 
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> GemFire:service=Manager,type=Member,member=locator2,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=System,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=Region,name=/region,type=Distributed,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]
> to contain:
>   [GemFire:type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=Manager,type=Member,member=locator1,
> 
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]
> but could not find the following element(s):
>   
> [GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1]
> at 
> org.apache.geode.management.JmxServerReconnectDistributedTest.lambda$null$7(JmxServerReconnectDistributedTest.java:203)
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9332) CI Failure: JmxServerReconnectDistributedTest > serverMXBeansOnServerAreUnaffectedByLocatorCrash

2021-05-27 Thread Owen Nichols (Jira)

Owen Nichols created GEODE-9332:
---

 Summary: CI Failure: JmxServerReconnectDistributedTest > 
serverMXBeansOnServerAreUnaffectedByLocatorCrash
 Key: GEODE-9332
 URL: https://issues.apache.org/jira/browse/GEODE-9332
 Project: Geode
  Issue Type: Test
  Components: jmx, tests
Reporter: Owen Nichols


{noformat}
java.lang.AssertionError: [GemFire mxbeans on locator2] 
Expecting HashSet:
  [GemFire:type=Member,member=locator1,

GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
GemFire:service=Region,name=/region,type=Member,member=server,
GemFire:service=Manager,type=Member,member=locator1,
GemFire:service=Locator,type=Member,member=locator2,
GemFire:type=Member,member=locator2,
GemFire:type=Member,member=server,
GemFire:service=FileUploader,type=Distributed,

GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
GemFire:service=Manager,type=Member,member=locator2,
GemFire:service=Locator,type=Member,member=locator1,
GemFire:service=System,type=Distributed,
GemFire:service=AccessControl,type=Distributed,

GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
GemFire:service=Region,name=/region,type=Distributed,

GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]
to contain:
  [GemFire:type=Member,member=locator1,
GemFire:service=Locator,type=Member,member=locator1,
GemFire:service=Manager,type=Member,member=locator1,

GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,

GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]
but could not find the following element(s):
  
[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1]
at 
org.apache.geode.management.JmxServerReconnectDistributedTest.lambda$null$7(JmxServerReconnectDistributedTest.java:203)
 {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException



[ 
https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352876#comment-17352876
 ] 

Geode Integration commented on GEODE-6183:
--

Seen in [WindowsCoreIntegrationTestOpenJDK11 
#246|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/246]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0270/test-results/integrationTest/1622156141/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0270/test-artifacts/1622156141/windows-coreintegrationtestfiles-OpenJDK11-1.15.0-build.0270.tgz].

> CI Failure: 
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed 
> with ConditionTimeoutException
> 
>
> Key: GEODE-6183
> URL: https://issues.apache.org/jira/browse/GEODE-6183
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Eric Shu
>Assignee: Kirk Lund
>Priority: Major
>  Time Spent: 5h 50m
>  Remaining Estimate: 0h
>
> Test failed in 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > 
> startDeletesStaleControlFiles FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that 
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but 
> was:<[not responding]> within 300 seconds.
> Caused by:
> org.junit.ComparisonFailure: expected:<[online]> but was:<[not 
> responding]>



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason



 [ 
https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9331:
--
Labels: GeodeOperationAPI pull-request-available  (was: GeodeOperationAPI)

> ConnectionTable maintains WeakReference to thread local map for no reason
> -
>
> Key: GEODE-9331
> URL: https://issues.apache.org/jira/browse/GEODE-9331
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> Every time a p2p thread owned connection is created it is added to a HashMap 
> kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap 
> is also added to an ArrayList. But this ArrayList is not actually used for 
> anything. It is iterated over in ConnectionTable.close to close any of the 
> thread local connections but all of these connections are also in the 
> "threadConnectionMap" which is iterated over during close.
> So the ArrayList "threadConnMaps" can be removed with no loss of 
> functionality. Getting rid of it will improve performance the first time a 
> thread creates a thread owned connection and will reduce the amount of memory 
> consumed (the ArrayList will have at least one entry for every thread using 
> thread owned connections but it may have more since the WeakReference can be 
> slow to be garbage collected). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9306) Implement ZINCRBY

2021-05-27 Thread ASF subversion and git services (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9306:
--
Labels: pull-request-available  (was: )

> Implement **ZINCRBY**
> -
>
> Key: GEODE-9306
> URL: https://issues.apache.org/jira/browse/GEODE-9306
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Priority: Major
>  Labels: pull-request-available
>
> Implement the ZINCRBY Redis command. https://redis.io/commands/zincrby
> AC
> Unit and integration tests for ZINCRBY command



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-8772) Make tests assign necessary ports in test JVM [PERMANENT]



[ 
https://issues.apache.org/jira/browse/GEODE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352772#comment-17352772
 ] 

ASF subversion and git services commented on GEODE-8772:


Commit 67c36264dcd2301768cfc63153ef4ea2ea4567fa in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=67c3626 ]

GEODE-8772: Disable HTTP service in Client Server TX test (#6529)

PROBLEM

`ClientServerTransactionFailoverWithMixedVersionServersDistributedTest`
launches a locator with HTTP service enabled on the default port (7070).
If these tests run in parallel outside of docker, each locator tries to
bind the HTTP service to port 7070, and all but the first will fail.

This happens even though the tests do not need the HTTP service.

THIS COMMIT

Starts the locators with HTTP service disabled.

Authored-by: Dale Emery 

> Make tests assign necessary ports in test JVM [PERMANENT]
> -
>
> Key: GEODE-8772
> URL: https://issues.apache.org/jira/browse/GEODE-8772
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> *Make tests assign all necessary ports.* Many distributed tests and upgrade 
> tests (and sometimes others) launch members with default ports, especially 
> for JMX (1099) and HTTP service (7070). When run in parallel outside of 
> docker, these tests often fail because the default port is already in use in 
> another test.
> Except when specifically testing the product's use of the defaults, every 
> test should assign ports from a pool of ports known to be available. For many 
> tests, we can accomplish this by changing the test framework to assign 
> available ports. Other tests may require changes in the test code.
> *Assign ports only in test JVMs, and not in child VMs.* The 
> {{AvailablePortHelper}} class occasionally gains new features to improve its 
> assignment of ports when tests run in parallel. For these improvements to 
> work, each test must use the latest {{AvailablePortHelper}} implementation 
> for all port assignments. Child VMs that run older versions of Geode may not 
> include the latest implementation of {{AvailablePortHelper}}. For this 
> reason, tests should invoke {{AvailablePortHelper}} only in the test JVM and 
> not in child VMs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason



 [ 
https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-9331:
---

Assignee: Darrel Schneider

> ConnectionTable maintains WeakReference to thread local map for no reason
> -
>
> Key: GEODE-9331
> URL: https://issues.apache.org/jira/browse/GEODE-9331
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Every time a p2p thread owned connection is created it is added to a HashMap 
> kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap 
> is also added to an ArrayList. But this ArrayList is not actually used for 
> anything. It is iterated over in ConnectionTable.close to close any of the 
> thread local connections but all of these connections are also in the 
> "threadConnectionMap" which is iterated over during close.
> So the ArrayList "threadConnMaps" can be removed with no loss of 
> functionality. Getting rid of it will improve performance the first time a 
> thread creates a thread owned connection and will reduce the amount of memory 
> consumed (the ArrayList will have at least one entry for every thread using 
> thread owned connections but it may have more since the WeakReference can be 
> slow to be garbage collected). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9285) make RedisSet's measurement of bytes in use more accurate



 [ 
https://issues.apache.org/jira/browse/GEODE-9285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9285:
--
Labels: pull-request-available redis  (was: redis)

> make RedisSet's measurement of bytes in use more accurate
> -
>
> Key: GEODE-9285
> URL: https://issues.apache.org/jira/browse/GEODE-9285
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
>  Labels: pull-request-available, redis
>
> RedisSet currently uses constants to help keep track of the size of bytes in 
> use by that RedisSet. The way that the size increases when members are added 
> is not constant, and is affected by resizing. It is possible to get the 
> measurement to be exactly accurate, by dynamically calculating the overhead 
> based on the current capacity and how many entries there are. In order to 
> test this with mocks, the delta will need to be set to null explicitly after 
> it is applied.
> This relates to: 
> https://github.com/apache/geode/commit/6a0eba25d5ed5cc7146ce6374d39dd12b22745f3



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason



 [ 
https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-9331:

Labels: GeodeOperationAPI  (was: )

> ConnectionTable maintains WeakReference to thread local map for no reason
> -
>
> Key: GEODE-9331
> URL: https://issues.apache.org/jira/browse/GEODE-9331
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Darrel Schneider
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Every time a p2p thread owned connection is created it is added to a HashMap 
> kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap 
> is also added to an ArrayList. But this ArrayList is not actually used for 
> anything. It is iterated over in ConnectionTable.close to close any of the 
> thread local connections but all of these connections are also in the 
> "threadConnectionMap" which is iterated over during close.
> So the ArrayList "threadConnMaps" can be removed with no loss of 
> functionality. Getting rid of it will improve performance the first time a 
> thread creates a thread owned connection and will reduce the amount of memory 
> consumed (the ArrayList will have at least one entry for every thread using 
> thread owned connections but it may have more since the WeakReference can be 
> slow to be garbage collected). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason



 [ 
https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-9331:

Issue Type: Improvement  (was: Bug)

> ConnectionTable maintains WeakReference to thread local map for no reason
> -
>
> Key: GEODE-9331
> URL: https://issues.apache.org/jira/browse/GEODE-9331
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Darrel Schneider
>Priority: Major
>
> Every time a p2p thread owned connection is created it is added to a HashMap 
> kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap 
> is also added to an ArrayList. But this ArrayList is not actually used for 
> anything. It is iterated over in ConnectionTable.close to close any of the 
> thread local connections but all of these connections are also in the 
> "threadConnectionMap" which is iterated over during close.
> So the ArrayList "threadConnMaps" can be removed with no loss of 
> functionality. Getting rid of it will improve performance the first time a 
> thread creates a thread owned connection and will reduce the amount of memory 
> consumed (the ArrayList will have at least one entry for every thread using 
> thread owned connections but it may have more since the WeakReference can be 
> slow to be garbage collected). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason

Darrel Schneider created GEODE-9331:
---

 Summary: ConnectionTable maintains WeakReference to thread local 
map for no reason
 Key: GEODE-9331
 URL: https://issues.apache.org/jira/browse/GEODE-9331
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Darrel Schneider


Every time a p2p thread owned connection is created it is added to a HashMap 
kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap 
is also added to an ArrayList. But this ArrayList is not actually used for 
anything. It is iterated over in ConnectionTable.close to close any of the 
thread local connections but all of these connections are also in the 
"threadConnectionMap" which is iterated over during close.

So the ArrayList "threadConnMaps" can be removed with no loss of functionality. 
Getting rid of it will improve performance the first time a thread creates a 
thread owned connection and will reduce the amount of memory consumed (the 
ArrayList will have at least one entry for every thread using thread owned 
connections but it may have more since the WeakReference can be slow to be 
garbage collected). 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9255) Remove ByteArrayWrapper From Project

2021-05-27 Thread ASF subversion and git services (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9255:
--
Labels: pull-request-available redis  (was: redis)

> Remove ByteArrayWrapper From Project
> 
>
> Key: GEODE-9255
> URL: https://issues.apache.org/jira/browse/GEODE-9255
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Wayne
>Assignee: Donal Evans
>Priority: Major
>  Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> After completion of all other stories, the ByteArrayWrapper can be removed 
> from the project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9279) Make redis deltas implement Sizeable



[ 
https://issues.apache.org/jira/browse/GEODE-9279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352726#comment-17352726
 ] 

ASF subversion and git services commented on GEODE-9279:


Commit c6d1da1059328daa0731d8493146152bb6a99594 in geode's branch 
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6d1da1 ]

GEODE-9222: Remove ByteArrayWrapper from RedisSet (#6487)

 - Replace uses of ByteArrayWrapper with byte[] in RedisSet,
 NullRedisSet and other Set-related classes
 - Replace internal Set in RedisSet with fastutil
 ObjectOpenCustomHashSet
 - Replace the membersAddAll and membersRemoveAll methods with looped
 calls to membersAdd and membersRemove, as ObjectOpenCustomHashSet does
 not implement removeAll, which causes errors when comparing
 the contents of Sets
 - Change implementation of sunionstore, sinterstore and sdiffstore to
 correctly use ObjectOpenCustomHashSet
 - Moving the set commands executor to a shared object rather than
 allocating it for each operation
 - Replace uses of collection implementations with interfaces where possible
 - Make RedisSet.smembers() public, similar to RedisHash.hkeys() and
 RedisHash.hvalue()
 - Change RedisSet.toString to be in line with other Redis classes
 - These changes break the sizing tests, but these tests have been
 determined to be inconsistent due to the current implementation of
 sizeable in RedisSet. GEODE-9279 will address the issues with sizeable
 in a future commit
 - These changes break backwards compatibility with Geode 1.14.0

Authored-by: Donal Evans 

> Make redis deltas implement Sizeable
> 
>
> Key: GEODE-9279
> URL: https://issues.apache.org/jira/browse/GEODE-9279
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Hale Bales
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.15.0
>
>
> In order for rebalances to work correctly, we must keep track of a close 
> estimate of the amount of data that we have. RedisString, RedisSet, and 
> RedisHash all inherit from RedisData, which implements Sizeable already. The 
> current calculations for set and hash are approximately correct, but do not 
> take into account the size of the delta that gets created when the data is 
> stored. In order to account for that additional overhead, the delta must also 
> implement Sizeable and keep track of its size. This will allow us to be much 
> more accurate in our calculations of bytes in use for Set and String, 
> potentially exactly accurate.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9222) Remove ByteArrayWrapperUsage From RedisSet

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352725#comment-17352725
 ] 

ASF subversion and git services commented on GEODE-9222:


Commit c6d1da1059328daa0731d8493146152bb6a99594 in geode's branch 
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6d1da1 ]

GEODE-9222: Remove ByteArrayWrapper from RedisSet (#6487)

 - Replace uses of ByteArrayWrapper with byte[] in RedisSet,
 NullRedisSet and other Set-related classes
 - Replace internal Set in RedisSet with fastutil
 ObjectOpenCustomHashSet
 - Replace the membersAddAll and membersRemoveAll methods with looped
 calls to membersAdd and membersRemove, as ObjectOpenCustomHashSet does
 not implement removeAll, which causes errors when comparing
 the contents of Sets
 - Change implementation of sunionstore, sinterstore and sdiffstore to
 correctly use ObjectOpenCustomHashSet
 - Moving the set commands executor to a shared object rather than
 allocating it for each operation
 - Replace uses of collection implementations with interfaces where possible
 - Make RedisSet.smembers() public, similar to RedisHash.hkeys() and
 RedisHash.hvalue()
 - Change RedisSet.toString to be in line with other Redis classes
 - These changes break the sizing tests, but these tests have been
 determined to be inconsistent due to the current implementation of
 sizeable in RedisSet. GEODE-9279 will address the issues with sizeable
 in a future commit
 - These changes break backwards compatibility with Geode 1.14.0

Authored-by: Donal Evans 

> Remove ByteArrayWrapperUsage From RedisSet
> --
>
> Key: GEODE-9222
> URL: https://issues.apache.org/jira/browse/GEODE-9222
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Wayne
>Assignee: Donal Evans
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The classes RedisSet and NullRedisSet should be refactored to eliminate the 
> use of ByteArrayWrapper and use byte[] instead.
>  
> When used as a key in a GeodeRegion, the new RedisKey class should be used as 
> a key instead of byte[].
>   
> +Acceptance Criteria+
> After this refactor, we must verify that all existing regression tests run 
> without failure.  Using the Redis Benchmarking tools, we expect an 
> improvement in transaction throughput.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (GEODE-9222) Remove ByteArrayWrapperUsage From RedisSet

2021-05-27 Thread Donal Evans (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donal Evans resolved GEODE-9222.

Resolution: Fixed

> Remove ByteArrayWrapperUsage From RedisSet
> --
>
> Key: GEODE-9222
> URL: https://issues.apache.org/jira/browse/GEODE-9222
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Wayne
>Assignee: Donal Evans
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The classes RedisSet and NullRedisSet should be refactored to eliminate the 
> use of ByteArrayWrapper and use byte[] instead.
>  
> When used as a key in a GeodeRegion, the new RedisKey class should be used as 
> a key instead of byte[].
>   
> +Acceptance Criteria+
> After this refactor, we must verify that all existing regression tests run 
> without failure.  Using the Redis Benchmarking tools, we expect an 
> improvement in transaction throughput.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (GEODE-9317) ZADD/ZSCORE do not properly handle infinity

2021-05-27 Thread Hale Bales (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hale Bales reassigned GEODE-9317:
-

Assignee: Hale Bales

> ZADD/ZSCORE do not properly handle infinity
> ---
>
> Key: GEODE-9317
> URL: https://issues.apache.org/jira/browse/GEODE-9317
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: Hale Bales
>Priority: Critical
>
> Native Redis accepts values like "inf", "+inf", "-infinity", etc. Currently 
> Radish considers these values invalid and returns "ERR value is not a valid 
> float".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (GEODE-9078) Remove ACE mutexes

2021-05-27 Thread Blake Bender (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Bender closed GEODE-9078.
---

> Remove ACE mutexes
> --
>
> Key: GEODE-9078
> URL: https://issues.apache.org/jira/browse/GEODE-9078
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS AN* geode-native contributor
>  *I WANT TO* remove all occurrences of ACE mutexes
>  *SO THAT* we can get rid of ACE for good



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (GEODE-9078) Remove ACE mutexes

2021-05-27 Thread Blake Bender (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Bender resolved GEODE-9078.
-
Resolution: Fixed

> Remove ACE mutexes
> --
>
> Key: GEODE-9078
> URL: https://issues.apache.org/jira/browse/GEODE-9078
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS AN* geode-native contributor
>  *I WANT TO* remove all occurrences of ACE mutexes
>  *SO THAT* we can get rid of ACE for good



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9078) Remove ACE mutexes

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352704#comment-17352704
 ] 

ASF GitHub Bot commented on GEODE-9078:
---

pdxcodemonkey merged pull request #776:
URL: https://github.com/apache/geode-native/pull/776


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove ACE mutexes
> --
>
> Key: GEODE-9078
> URL: https://issues.apache.org/jira/browse/GEODE-9078
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS AN* geode-native contributor
>  *I WANT TO* remove all occurrences of ACE mutexes
>  *SO THAT* we can get rid of ACE for good



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9078) Remove ACE mutexes



[ 
https://issues.apache.org/jira/browse/GEODE-9078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352703#comment-17352703
 ] 

ASF subversion and git services commented on GEODE-9078:


Commit 76615158194c51a4ccace652f1f93f4571c83c67 in geode-native's branch 
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=7661515 ]

GEODE-9078: Remove ACE mutexes (#776)

 - Removed all ACE mutexes.
 - Solved header inclusion leak in order to avoid linking Boost to
   testobject.
 - TODO. Review mutex usage in PdxType as it is only used to read, so
   either it's not necessary or we are missing write locks.
 - Removed testTimedSemaphore old ITs as ACE_Semaphore is not used
   anymore.
 - Changed member variable naming to the current standard for
   AdminRegion class.
 - Got rid of TryReadGuard and TryWriteGuard as it's not really
   necessary. Code has been refactored so it uses plain shared_mutex
   instead.
 - shared_mutex from AdminRegion, RemoteQueryService and
   ThinClientRegion are not publicly exposed anymore. For correctness,
   locks are exposed instead.
 - Reverted naming change on member variables for class AdminRegion.
 - Fixed exception in .Net integration tests. An exception with message
   "The string binding is invalid" was being thrown due to the fact that
   the Apache.Geode DLL has mixed code and compiles with CLR enabled.
   That's something dis-recommended by Boost because under certain
   conditions could cause problems with boost static variables.
   In this case the issue was related to one of the boost::exception
   static variables.
   This issue was solved by removing header inclusion introduced in
   revision 3.
 - Due to above issue, exposing the lock rather than the mutex is not
   possible for now, until a further refactor is made to .Net code, so
   mutex/lock exposition from revision 3 has been reverted.
 - As it was determined, there is no need to guarantee exclusive access
   to PdxTypes, so both remains of shared_lock are removed.
 - Also, removed ReadWriteLock, as it's not necessary anymore.

> Remove ACE mutexes
> --
>
> Key: GEODE-9078
> URL: https://issues.apache.org/jira/browse/GEODE-9078
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS AN* geode-native contributor
>  *I WANT TO* remove all occurrences of ACE mutexes
>  *SO THAT* we can get rid of ACE for good



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-8772) Make tests assign necessary ports in test JVM [PERMANENT]

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352701#comment-17352701
 ] 

ASF subversion and git services commented on GEODE-8772:


Commit 168bf86ebc8e0ef9df9be06143669bfe97654ab6 in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=168bf86 ]

GEODE-8772: WAN upgrade test port assignment (#6522)

Change `WANRollingUpgradeDUnitTest` and
`WANRollingUpgradeCreateSenderGatewaySenderMixedSiteOneCurrentSiteTwo`
to assign ports only in the test JVM.

BACKGROUND

As part of my project to allow Geode tests to run in parallel outside of
Docker, I am changing our build system to allocate a distinct range of
ports to each test JVM, and changing `AvailablePort` and
`AvailablePortHelper` to honor these allocated port ranges.

This commit prepares for those changes.

PROBLEM

- `WANRollingUpgradeCreateSenderGatewaySenderMixedSiteOneCurrentSiteTwo`
  calls `startLocatorWithJmxManager()` in a child VM running a prior
  version of Geode. This method then calls `AvailablePortHelper` to get
  a JMX manager port.
- `WANRollingUpgradeDUnitTest` calls `addCacheServer()` in a child VM
  running a prior version of Geode. This method them calls
  `AvailablePortHelper` to get a server port.
- In each case, the old implementation of `AvailablePortHelper` in the
  child VM does not honor the range of ports allocated to the test.
- If these tests run in parallel outside of Docker, the old
  implementations of `AvailablePortHelper` may assign the same port
  number in each test.  If different tests try to bind to the same port
  at the same time, all but one will fail.

GENERAL SOLUTION

Make tests assign ports only in the test JVM. The test JVM always
includes the latest implementations of `AvailablePort` and
`AvailablePortHelper`, and so the tests  will honor any port allocation
scheme defined in the latest implementation.

THIS COMMIT

- Change `startLocatorWithJmxManager()` and `addCacheServer()` to be
  factory functions that take the relevant port as a parameter and
  return a `SerializableRunnable` that serializes the port and can be
  invoked in the child VM.
- Change each test to assign the relevant port in the test JVM, call the
  relevant factory method to get a runnable, and execute the runnable in
  the child VM.

In this way, all ports are assigned in the test JVM, which includes the
latest implementation of `AvailablePortHelper`, which will (after my
eventual enhancement) honor the port ranges allocated to the test JVM
and ensure that no two tests try to bind to the same port.

> Make tests assign necessary ports in test JVM [PERMANENT]
> -
>
> Key: GEODE-8772
> URL: https://issues.apache.org/jira/browse/GEODE-8772
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> *Make tests assign all necessary ports.* Many distributed tests and upgrade 
> tests (and sometimes others) launch members with default ports, especially 
> for JMX (1099) and HTTP service (7070). When run in parallel outside of 
> docker, these tests often fail because the default port is already in use in 
> another test.
> Except when specifically testing the product's use of the defaults, every 
> test should assign ports from a pool of ports known to be available. For many 
> tests, we can accomplish this by changing the test framework to assign 
> available ports. Other tests may require changes in the test code.
> *Assign ports only in test JVMs, and not in child VMs.* The 
> {{AvailablePortHelper}} class occasionally gains new features to improve its 
> assignment of ports when tests run in parallel. For these improvements to 
> work, each test must use the latest {{AvailablePortHelper}} implementation 
> for all port assignments. Child VMs that run older versions of Geode may not 
> include the latest implementation of {{AvailablePortHelper}}. For this 
> reason, tests should invoke {{AvailablePortHelper}} only in the test JVM and 
> not in child VMs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352695#comment-17352695
 ] 

ASF subversion and git services commented on GEODE-9307:


Commit 2bc4bd93a6c24ea32c3a44c502fcb20c0a255cb4 in geode's branch 
refs/heads/develop from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2bc4bd9 ]

GEODE-9307: Removed MembershipListener after force disconnect (#6515)



> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (GEODE-8910) Native libraries should hash key objects similarly to their Java counterparts

2021-05-27 Thread Jacob Barrett (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-8910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacob Barrett resolved GEODE-8910.
--
Fix Version/s: 1.15.0
   Resolution: Fixed

> Native libraries should hash key objects similarly to their Java counterparts
> -
>
> Key: GEODE-8910
> URL: https://issues.apache.org/jira/browse/GEODE-8910
> Project: Geode
>  Issue Type: Improvement
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Current not all the C++ or .NET types consistently hash to values consistent 
> with the Java server. This can result in multi hop operations. Also, not all 
> hashing algorithms are publicly accessible to in the library. 
> The C++ and .NET libraries should expose hashing functions consistent with 
> Java that are easy to use both internally and by user defined keys.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (GEODE-9191) PR clear could miss clearing bucket which lost primary

2021-05-27 Thread Xiaojian Zhou (Jira)

[
https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339313#comment-17339313
]

Xiaojian Zhou edited comment on GEODE-9191 at 5/27/21, 6:30 PM:

More investigation found that the primary buckets could switch at any time
especially when they are not balanced (usually happened in GII). We need to
lock the primary from moving.

The revised design will be:

(1) coordinator(a server) assignAllBuckets.

(2) coordinator lock local primary buckets and sends lock message to all peer
members.

(3) upon received the lock message, each datastore server will:
- lockBucketCreationForRegionClear (Maybe we don't need it)
- waits for all the primaries to show up
- iterate through local primary bucket list to lock primary from moving, then
lock RVV
- reply with number of buckets locked

(4) coordinator collected locked bucket numbers from each member, if matched
the expected total bucket number (i.e. default is 113), move on to next step.
Otherwise, retry.
- It's possible while iterating through the local primary bucket list, some of
the primary bucket is no longer primary, in this case, the sum of locked
primary bucket numbers that collected by the coordinator could be different
with the expected total bucket number.
Then coordinator will unlock all the members and retry.
- Retry until succeed or failed with PartialClearException. Retry will usually
succeed, unless there're too many servers shutdown. In that case,
waitForPrimary will fail with PartialClearException and break the endless
retry.

(5) If a member is down, the membership listener will detected and let
coordinator to retry. If too many members are down, wait for primary should
fail with PartitionedRegionPartialClearException. Then coordinator will unlock
and throw this exception to caller. If the coordinator is down, the pr clear
will fail.
Note: membership listener will trigger coordinator to retry from beginning, not
to let each member to retry locally, because the primary list might have
changed.

(6) After locked all the members' primary buckets (both locked primary and
locked RVV), the coordinator sends clear message to all the members.

(7) each member clear primary buckets one by one and return number of buckets
cleared.

(8) Coordinator collect all the numbers cleared, if less than expected bucket
number, retry. This could happen when a member is offline in the middle of
clear. The retry should succeed finally unless too many servers are down. Then
the waitForPrimary will throw PartialClearException.

(9) In unlock, the coordinator should send UNLOCK message to all the members to
unlock not only primary buckets, because the primary list at each member could
have been changed.
- should iterate through all the local buckets and unlock RVV, then unlock
primary moving.
- getLockRequester()==null means coordinator is down. In that case, we should
still do unlock.
- Since the PR clear will retry forever until succeeded or fail with
ParticlalClearException due to too many members are down, there's no need to
lockBucketCreationForRegionClear.
- if a member is down, the listener is triggered at all the members, these
members will check who is down. If the down member is the non-coordinator, then
coordinator will notify all other members to unlock and cleanup. If it’s the
coordinator shutdown, other members should unlock and cleanup.
- if coordinator is down: should rely on listener to let each member to unlock
their own local buckets (unlock on unlocked buckets is ok)

Test cases to be added in other geode ticket:
(1) secondary become new primary which is unlocked, how the on-going operation
sync with pr clear
(2) a new operation create a new bucket which is also a primary, how to sync
with pr clear|
(3) fixed partition, how it sync with assignAllBuckets and PR clear
(4) if shutdown 2 servers in redundancy=1, should call assignAllBuckets() to
recreate buckets in existing servers, unless PartitionOfflineException

was (Author: zhouxj):
More investigation found that the primary buckets could switch at any time
especially when they are not balanced (usually happened in GII). We need to
lock the primary from moving.

The revised design will be:

(1) coordinator(a server) assignAllBuckets.

(2) coordinator lock local primary buckets and sends lock message to all peer
members.

[jira] [Created] (GEODE-9330) CI Failure: StandaloneClientManagementAPIAcceptanceTest > clientCreatesRegionUsingClusterManagementService

2021-05-27 Thread Owen Nichols (Jira)

Owen Nichols created GEODE-9330:
---

 Summary: CI Failure: StandaloneClientManagementAPIAcceptanceTest > 
clientCreatesRegionUsingClusterManagementService
 Key: GEODE-9330
 URL: https://issues.apache.org/jira/browse/GEODE-9330
 Project: Geode
  Issue Type: Test
  Components: tests
Reporter: Owen Nichols


this is different from GEODE-6784 because the startup rule returns failure, 
rather than a timeout being exceeded:
{noformat}
org.apache.geode.management.internal.rest.StandaloneClientManagementAPIAcceptanceTest
 > clientCreatesRegionUsingClusterManagementService[1] FAILED
org.junit.ComparisonFailure: [Exit value from process started by 
[startCluster: gfsh -e start locator --port=28921 --http-service-port=28922 
--J=-Dgemfire.JMX_MANAGER_PORT=28923  -e start server 
--locators=localhost[28921] --server-port=0]] expected:<[0]> but was:<[1]>
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
at 
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
at 
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
at 
org.apache.geode.management.internal.rest.StandaloneClientManagementAPIAcceptanceTest.clientCreatesRegionUsingClusterManagementService(StandaloneClientManagementAPIAcceptanceTest.java:115)
 {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9330) CI Failure: StandaloneClientManagementAPIAcceptanceTest > clientCreatesRegionUsingClusterManagementService



[ 
https://issues.apache.org/jira/browse/GEODE-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352660#comment-17352660
 ] 

Geode Integration commented on GEODE-9330:
--

Seen in [WindowsAcceptanceTestOpenJDK11 
#242|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK11/builds/242]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0268/test-results/acceptanceTest/1622079958/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0268/test-artifacts/1622079958/windows-acceptancetestfiles-OpenJDK11-1.15.0-build.0268.tgz].

> CI Failure: StandaloneClientManagementAPIAcceptanceTest > 
> clientCreatesRegionUsingClusterManagementService
> --
>
> Key: GEODE-9330
> URL: https://issues.apache.org/jira/browse/GEODE-9330
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Owen Nichols
>Priority: Major
>
> this is different from GEODE-6784 because the startup rule returns failure, 
> rather than a timeout being exceeded:
> {noformat}
> org.apache.geode.management.internal.rest.StandaloneClientManagementAPIAcceptanceTest
>  > clientCreatesRegionUsingClusterManagementService[1] FAILED
> org.junit.ComparisonFailure: [Exit value from process started by 
> [startCluster: gfsh -e start locator --port=28921 --http-service-port=28922 
> --J=-Dgemfire.JMX_MANAGER_PORT=28923  -e start server 
> --locators=localhost[28921] --server-port=0]] expected:<[0]> but was:<[1]>
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> at 
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at 
> org.apache.geode.management.internal.rest.StandaloneClientManagementAPIAcceptanceTest.clientCreatesRegionUsingClusterManagementService(StandaloneClientManagementAPIAcceptanceTest.java:115)
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-8971) Batches with incomplete transactions when stopping the gateway sender

2021-05-27 Thread ASF subversion and git services (Jira)



[ 
https://issues.apache.org/jira/browse/GEODE-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352629#comment-17352629
 ] 

Geode Integration commented on GEODE-8971:
--

Seen in [WindowsUnitTestOpenJDK11 
#244|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/244]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0269/test-results/test/1622134831/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0269/test-artifacts/1622134831/windows-unittestfiles-OpenJDK11-1.15.0-build.0269.tgz].

> Batches with incomplete transactions when stopping the gateway sender
> -
>
> Key: GEODE-8971
> URL: https://issues.apache.org/jira/browse/GEODE-8971
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Affects Versions: 1.14.0
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> When the gateway sender is stopped there is a high probability that batches 
> with incomplete transactions are sent even if group-transaction-events is 
> enabled.
> The reason is that once the stop command reaches the gateway sender, it 
> immediately stops queueing events, and this could happen in the middle of 
> receiving events for the same transaction. If this is the case, some events 
> for the transaction may have reached the queue right before the stop command 
> was received and the rest of events for that transaction would not make it to 
> the queue (they would be dropped) because they arrived right after the stop 
> command was received at the gateway sender.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-8772) Make tests assign necessary ports in test JVM [PERMANENT]



[ 
https://issues.apache.org/jira/browse/GEODE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352608#comment-17352608
 ] 

ASF subversion and git services commented on GEODE-8772:


Commit 093f1864cb941b23ba2c4e7a3303e7e47eac85ca in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=093f1864 ]

GEODE-8772: ClientServer test port assignment (#6513)

Change `ClientServerMiscDUnitTestBase`, `ClientServerMiscDUnitTest`, and
`ClientServerMiscBCDUnitTest` to assign ports only in the test JVM.

BACKGROUND

As part of my project to allow Geode tests to run in parallel outside of
Docker, I am changing our build system to allocate a distinct range of
ports to each test JVM, and changing `AvailablePort` and
`AvailablePortHelper` to honor these allocated port ranges.

This commit prepares for those changes.

PROBLEM

To test compatibility, `ClientServerMiscDUnitTestBase` executes
`createServerCache()` in a child VMs running old versions of Geode. The
`createServerCache()` method assigns a server port via
`AvailablePortHelper`.  The old implementation of `AvailablePortHelper`
in the child VM does not honor the range of ports allocated to the child
VM.

If such tests run in parallel outside of Docker, the
`createServerCache()` method in each test may assign the same port. If
the servers in multiple tests attempt to bind to that port at the same
time, all but one server will fail.

GENERAL SOLUTION

Make tests assign ports only in the test JVM. The test JVM always
includes the latest implementations of `AvailablePort` and
`AvailablePortHelper`, and so the tests  will honor any port allocation
scheme defined in the latest implementation.

THIS COMMIT

- Add a `port` parameter to `createServerCache()`.
- Change `ClientServerMiscDUnitTestBase`, `ClientServerMiscDUnitTest`,
  and `ClientServerMiscBCDUnitTest` to assign ports only methods called
  in the test JVM.

> Make tests assign necessary ports in test JVM [PERMANENT]
> -
>
> Key: GEODE-8772
> URL: https://issues.apache.org/jira/browse/GEODE-8772
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> *Make tests assign all necessary ports.* Many distributed tests and upgrade 
> tests (and sometimes others) launch members with default ports, especially 
> for JMX (1099) and HTTP service (7070). When run in parallel outside of 
> docker, these tests often fail because the default port is already in use in 
> another test.
> Except when specifically testing the product's use of the defaults, every 
> test should assign ports from a pool of ports known to be available. For many 
> tests, we can accomplish this by changing the test framework to assign 
> available ports. Other tests may require changes in the test code.
> *Assign ports only in test JVMs, and not in child VMs.* The 
> {{AvailablePortHelper}} class occasionally gains new features to improve its 
> assignment of ports when tests run in parallel. For these improvements to 
> work, each test must use the latest {{AvailablePortHelper}} implementation 
> for all port assignments. Child VMs that run older versions of Geode may not 
> include the latest implementation of {{AvailablePortHelper}}. For this 
> reason, tests should invoke {{AvailablePortHelper}} only in the test JVM and 
> not in child VMs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9324) Remove ACE_Task references



[ 
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352552#comment-17352552
 ] 

ASF GitHub Bot commented on GEODE-9324:
---

gaussianrecurrence opened a new pull request #812:
URL: https://github.com/apache/geode-native/pull/812


- Removed all references to ACE_Task


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9324) Remove ACE_Task references



 [ 
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9324:
--
Labels: obliterate-ace pull-request-available  (was: obliterate-ace)

> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9323) Remove ACE references from tests/cpp



 [ 
https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9323:
--
Labels: obliterate-ace pull-request-available  (was: obliterate-ace)

> Remove ACE references from tests/cpp
> 
>
> Key: GEODE-9323
> URL: https://issues.apache.org/jira/browse/GEODE-9323
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE in tests/cpp projects
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9323) Remove ACE references from tests/cpp



[ 
https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352513#comment-17352513
 ] 

ASF GitHub Bot commented on GEODE-9323:
---

gaussianrecurrence opened a new pull request #811:
URL: https://github.com/apache/geode-native/pull/811


- Removed all ACE references from tests/cpp projects.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Remove ACE references from tests/cpp
> 
>
> Key: GEODE-9323
> URL: https://issues.apache.org/jira/browse/GEODE-9323
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE in tests/cpp projects
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9329) Implement data structures needed for Redis leaderboard use case

2021-05-27 Thread Ray Ingles (Jira)

Ray Ingles created GEODE-9329:
-

 Summary: Implement data structures needed for Redis leaderboard 
use case
 Key: GEODE-9329
 URL: https://issues.apache.org/jira/browse/GEODE-9329
 Project: Geode
  Issue Type: New Feature
  Components: redis
Affects Versions: 1.15.0
Reporter: Ray Ingles


Implement the data structures needed to fully support Sorted Sets in Radish.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9324) Remove ACE_Task references



 [ 
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9324:
---
Labels: obliterate-ace  (was: )

> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9323) Remove ACE references from tests/cpp



 [ 
https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9323:
---
Labels: obliterate-ace  (was: )

> Remove ACE references from tests/cpp
> 
>
> Key: GEODE-9323
> URL: https://issues.apache.org/jira/browse/GEODE-9323
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE in tests/cpp projects
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9328) Cleanup remains of ACE library

Mario Salazar de Torres created GEODE-9328:
--

 Summary: Cleanup remains of ACE library
 Key: GEODE-9328
 URL: https://issues.apache.org/jira/browse/GEODE-9328
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE library
*SO THAT* eventually we can get rid of ACE library

*Additional information.* Note that all header inclusions, lib linkage and 
CMake dependency project will need to be cleaned up here.

Also, additional changes might be needed to make the project compile, take it 
into account.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9325) Remove ACE_Process references



 [ 
https://issues.apache.org/jira/browse/GEODE-9325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9325:
---
Labels: obliterate-ace  (was: )

> Remove ACE_Process references
> -
>
> Key: GEODE-9325
> URL: https://issues.apache.org/jira/browse/GEODE-9325
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Process
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9327) Remove all remaining references to ACE networking



 [ 
https://issues.apache.org/jira/browse/GEODE-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9327:
---
Labels: obliterate-ace  (was: )

> Remove all remaining references to ACE networking
> -
>
> Key: GEODE-9327
> URL: https://issues.apache.org/jira/browse/GEODE-9327
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE networking
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9326) Remove ACE_Get_Opt references



 [ 
https://issues.apache.org/jira/browse/GEODE-9326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9326:
---
Labels: obliterate-ace  (was: )

> Remove ACE_Get_Opt references
> -
>
> Key: GEODE-9326
> URL: https://issues.apache.org/jira/browse/GEODE-9326
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Get_Opt
> *SO THAT* eventually we can get rid of ACE library
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9328) Cleanup remains of ACE library



 [ 
https://issues.apache.org/jira/browse/GEODE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres updated GEODE-9328:
---
Labels: obliterate-ace  (was: )

> Cleanup remains of ACE library
> --
>
> Key: GEODE-9328
> URL: https://issues.apache.org/jira/browse/GEODE-9328
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Mario Salazar de Torres
>Priority: Major
>  Labels: obliterate-ace
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE library
> *SO THAT* eventually we can get rid of ACE library
> 
> *Additional information.* Note that all header inclusions, lib linkage and 
> CMake dependency project will need to be cleaned up here.
> Also, additional changes might be needed to make the project compile, take it 
> into account.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9327) Remove all remaining references to ACE networking

Mario Salazar de Torres created GEODE-9327:
--

 Summary: Remove all remaining references to ACE networking
 Key: GEODE-9327
 URL: https://issues.apache.org/jira/browse/GEODE-9327
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE networking
*SO THAT* eventually we can get rid of ACE library

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9326) Remove ACE_Get_Opt references

Mario Salazar de Torres created GEODE-9326:
--

 Summary: Remove ACE_Get_Opt references
 Key: GEODE-9326
 URL: https://issues.apache.org/jira/browse/GEODE-9326
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE_Get_Opt
*SO THAT* eventually we can get rid of ACE library

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9325) Remove ACE_Process references

Mario Salazar de Torres created GEODE-9325:
--

 Summary: Remove ACE_Process references
 Key: GEODE-9325
 URL: https://issues.apache.org/jira/browse/GEODE-9325
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE_Process
*SO THAT* eventually we can get rid of ACE library

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9323) Remove ACE references from tests/cpp

Mario Salazar de Torres created GEODE-9323:
--

 Summary: Remove ACE references from tests/cpp
 Key: GEODE-9323
 URL: https://issues.apache.org/jira/browse/GEODE-9323
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE in tests/cpp projects
*SO THAT* eventually we can get rid of ACE library

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9324) Remove ACE_Task references

Mario Salazar de Torres created GEODE-9324:
--

 Summary: Remove ACE_Task references
 Key: GEODE-9324
 URL: https://issues.apache.org/jira/browse/GEODE-9324
 Project: Geode
  Issue Type: Improvement
  Components: native client
Reporter: Mario Salazar de Torres


*AS A* native client contributor
*I WANT TO* remove all remaining references to ACE_Task
*SO THAT* eventually we can get rid of ACE library

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (GEODE-9312) Uplift Bookbinder to 10.1.17

2021-05-27 Thread Alberto Bustamante Reyes (Jira)



 [ 
https://issues.apache.org/jira/browse/GEODE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alberto Bustamante Reyes resolved GEODE-9312.
-
Fix Version/s: 1.15.0
   Resolution: Fixed

> Uplift Bookbinder to 10.1.17
> 
>
> Key: GEODE-9312
> URL: https://issues.apache.org/jira/browse/GEODE-9312
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Uplift Bookbinder to use new 10.1.17 version, which solves the problems with 
> mimemagic library reported in GEODE-9042.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9042) Geode User Guide: update dockerfile to use newer ruby & gems



 [ 
https://issues.apache.org/jira/browse/GEODE-9042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9042:
--
Labels: pull-request-available  (was: )

> Geode User Guide: update dockerfile to use newer ruby & gems
> 
>
> Key: GEODE-9042
> URL: https://issues.apache.org/jira/browse/GEODE-9042
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, tools
>Affects Versions: 1.13.1
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
>
> The scripts that build the user guide are pinned at Ruby 2.3.0 and Bookbinder 
> 1.10.14.
> These need to be updated to Ruby 2.5.3 (or later) and Bookbinder 1.10.15 in 
> order to support current deployment infrastructure.
> Path to the Bookbinder gem: 
> http://docs-wiki.cfapps.io/wiki/bookbinder/installing-bookbinder.html#v10



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9322) Solve potential race condition in TransactionCleaningTest



 [ 
https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9322:
--
Labels: pull-request-available  (was: )

> Solve potential race condition in TransactionCleaningTest
> -
>
> Key: GEODE-9322
> URL: https://issues.apache.org/jira/browse/GEODE-9322
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: pull-request-available
>
> A possible race condition was detected in this new IT.
> Given there is no check for servers start/stop, it might happen that the test 
> proceeds before the server is actually stopped/started.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9322) Solve potential race condition in TransactionCleaningTest



[ 
https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352393#comment-17352393
 ] 

ASF GitHub Bot commented on GEODE-9322:
---

gaussianrecurrence opened a new pull request #810:
URL: https://github.com/apache/geode-native/pull/810


- Solved a potential race condition in TransactionCleaningTest TS
  due to the fact that no checks were performed after starting/stopping
  the server.
- Added gmock_actions helper to avoid gmock actions duplication.
- Modified RegisterKeysTest to use gmock_actions helper.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Solve potential race condition in TransactionCleaningTest
> -
>
> Key: GEODE-9322
> URL: https://issues.apache.org/jira/browse/GEODE-9322
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> A possible race condition was detected in this new IT.
> Given there is no check for servers start/stop, it might happen that the test 
> proceeds before the server is actually stopped/started.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (GEODE-9322) Solve potential race condition in TransactionCleaningTest



 [ 
https://issues.apache.org/jira/browse/GEODE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres reassigned GEODE-9322:
--

Assignee: Mario Salazar de Torres

> Solve potential race condition in TransactionCleaningTest
> -
>
> Key: GEODE-9322
> URL: https://issues.apache.org/jira/browse/GEODE-9322
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> A possible race condition was detected in this new IT.
> Given there is no check for servers start/stop, it might happen that the test 
> proceeds before the server is actually stopped/started.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9322) Solve potential race condition in TransactionCleaningTest

Mario Salazar de Torres created GEODE-9322:
--

 Summary: Solve potential race condition in TransactionCleaningTest
 Key: GEODE-9322
 URL: https://issues.apache.org/jira/browse/GEODE-9322
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Mario Salazar de Torres


A possible race condition was detected in this new IT.
Given there is no check for servers start/stop, it might happen that the test 
proceeds before the server is actually stopped/started.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9321) Solve potential race condition in ServerDisconnect.WithRegionDisconnectedListener IT



 [ 
https://issues.apache.org/jira/browse/GEODE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9321:
--
Labels: pull-request-available  (was: )

> Solve potential race condition in 
> ServerDisconnect.WithRegionDisconnectedListener IT
> 
>
> Key: GEODE-9321
> URL: https://issues.apache.org/jira/browse/GEODE-9321
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>  Labels: pull-request-available
>
> While making the effort to remove ACE I noticed that this test stops the 
> server and stablishes no cehck to verify whether or not the server has been 
> actually stopped while proceeding with the test.
> So, in scenarios where the test continues and the server has not yet been 
> stopped it might fail.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (GEODE-9321) Solve potential race condition in ServerDisconnect.WithRegionDisconnectedListener IT



[ 
https://issues.apache.org/jira/browse/GEODE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17352378#comment-17352378
 ] 

ASF GitHub Bot commented on GEODE-9321:
---

gaussianrecurrence opened a new pull request #809:
URL: https://github.com/apache/geode-native/pull/809


- Solved a possible race condition in ServerDisconnectWithListener TS
  due to the fact that there was no check to verify the server was
  actually stopped.
- Also added gmock_actions helper to avoid duplication.
- Modified RegisterKeysTest to use gmock_actions helper.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Solve potential race condition in 
> ServerDisconnect.WithRegionDisconnectedListener IT
> 
>
> Key: GEODE-9321
> URL: https://issues.apache.org/jira/browse/GEODE-9321
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> While making the effort to remove ACE I noticed that this test stops the 
> server and stablishes no cehck to verify whether or not the server has been 
> actually stopped while proceeding with the test.
> So, in scenarios where the test continues and the server has not yet been 
> stopped it might fail.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (GEODE-9321) Solve potential race condition in ServerDisconnect.WithRegionDisconnectedListener IT



 [ 
https://issues.apache.org/jira/browse/GEODE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mario Salazar de Torres reassigned GEODE-9321:
--

Assignee: Mario Salazar de Torres

> Solve potential race condition in 
> ServerDisconnect.WithRegionDisconnectedListener IT
> 
>
> Key: GEODE-9321
> URL: https://issues.apache.org/jira/browse/GEODE-9321
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
>
> While making the effort to remove ACE I noticed that this test stops the 
> server and stablishes no cehck to verify whether or not the server has been 
> actually stopped while proceeding with the test.
> So, in scenarios where the test continues and the server has not yet been 
> stopped it might fail.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (GEODE-9321) Solve potential race condition in ServerDisconnect.WithRegionDisconnectedListener IT

Mario Salazar de Torres created GEODE-9321:
--

 Summary: Solve potential race condition in 
ServerDisconnect.WithRegionDisconnectedListener IT
 Key: GEODE-9321
 URL: https://issues.apache.org/jira/browse/GEODE-9321
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Mario Salazar de Torres


While making the effort to remove ACE I noticed that this test stops the server 
and stablishes no cehck to verify whether or not the server has been actually 
stopped while proceeding with the test.

So, in scenarios where the test continues and the server has not yet been 
stopped it might fail.

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (GEODE-9194) Move PR clear related statistics to the appropriate classes