[jira] [Resolved] (GEODE-8879) Redis: add unknown command response for internal commands

2021-01-29 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-8879.
-
Fix Version/s: 1.14.0
   Resolution: Fixed

> Redis: add unknown command response for internal commands
> -
>
> Key: GEODE-8879
> URL: https://issues.apache.org/jira/browse/GEODE-8879
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.14.0
>
>
> We have several of 'internal' commands that are not intended to be executed 
> by users. When a user does execute one of these commands the server throws a 
> NPE and the response is: `ERR The server had an internal error please try 
> again`.
> The reponse should be the normal `ERR unknown command ''...`



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


[jira] [Assigned] (GEODE-8881) Redis: move HKEYS command to supported commands

2021-01-28 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8881:
---

Assignee: Helena Bales

> Redis: move HKEYS command to supported commands
> ---
>
> Key: GEODE-8881
> URL: https://issues.apache.org/jira/browse/GEODE-8881
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
>
> Write unit/integration tests that run against both Geode Redis and native 
> Redis, and dunit tests which test multiple concurrent clients accessing 
> different servers for the following command:
> HKEYS
> A.C.
> Unit/integration tests for both Geode and native Redis passing
> DUNIT tests passing
> README/redis_api_for_geode.html.md.erb updated to make command "supported"
> or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Assigned] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats

2021-01-28 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8859:
---

Assignee: Raymond Ingles

> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
>  Issue Type: Bug
>  Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Raymond Ingles
>Priority: Major
>  Labels: release-blocker
>
> Here is a comment from Darrel regarding this issue. For some background, the 
> Redis structures implement {{Delta}}.
>  
> {quote}I was playing around with RedisInsight and was able to get most the 
> the overview dashboard and the data browser working with geode redis. But I 
> found a problem with how we are using geode that causes the geode stats that 
> track how much data is stored in a partitioned region to be wrong and the 
> bucket sizes used for rebalancing are also wrong. Basically when we do create 
> ops on the region the stats track it okay. But when we do updates then geode 
> always thinks that nothing (size wise) changed. So for example I created a 
> string by doing a redis “set” command. I saw the size of the string accounted 
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on 
> that key and the dataStoreBytesInUse did not change at all. I think the 
> problem is in how we are updating the data structure in place instead of 
> getting a copy, modifying it, and then putting the copy into the region. 
> Avoiding this copy gives us MUCH better performance but it messes up geode 
> when it is trying to calculate the memory increase or decrease. It is 
> possible that this is only an issue on the primary and that the secondary 
> sizing may be correct. If so that could lead to other problems because for a 
> given bucket our primary size would be different than the secondary. The 
> bucket sizes are used when you do a rebalance but basically we can have a 
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced 
> but geode will think the buckets are balanced. I’m not sure what we should do 
> about this.
> {quote}



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


[jira] [Created] (GEODE-8885) Redis: test HINCRBY command

2021-01-28 Thread Helena Bales (Jira)
Helena Bales created GEODE-8885:
---

 Summary: Redis: test HINCRBY command
 Key: GEODE-8885
 URL: https://issues.apache.org/jira/browse/GEODE-8885
 Project: Geode
  Issue Type: Test
  Components: redis
Reporter: Helena Bales


Write unit/integration tests that run against both Geode Redis and native 
Redis, and dunit tests which test multiple concurrent clients accessing 
different servers for the following command:

HINCRBY

A.C.

Unit/integration tests for both Geode and native Redis passing
DUNIT tests passing
README/redis_api_for_geode.html.md.erb updated to make command "supported"
or
Stories in the backlog to fix the identified issues (with JIRA tickets) and 
problem tests ignored



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


[jira] [Assigned] (GEODE-8879) Redis: add unknown command response for internal commands

2021-01-28 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8879:
---

Assignee: Helena Bales

> Redis: add unknown command response for internal commands
> -
>
> Key: GEODE-8879
> URL: https://issues.apache.org/jira/browse/GEODE-8879
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
>
> We have several of 'internal' commands that are not intended to be executed 
> by users. When a user does execute one of these commands the server throws a 
> NPE and the response is: `ERR The server had an internal error please try 
> again`.
> The reponse should be the normal `ERR unknown command ''...`



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


[jira] [Assigned] (GEODE-8885) Redis: test HINCRBY command

2021-01-28 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8885:
---

Assignee: Helena Bales

> Redis: test HINCRBY command
> ---
>
> Key: GEODE-8885
> URL: https://issues.apache.org/jira/browse/GEODE-8885
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Write unit/integration tests that run against both Geode Redis and native 
> Redis, and dunit tests which test multiple concurrent clients accessing 
> different servers for the following command:
> HINCRBY
> A.C.
> Unit/integration tests for both Geode and native Redis passing
> DUNIT tests passing
> README/redis_api_for_geode.html.md.erb updated to make command "supported"
> or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Created] (GEODE-8881) Redis: move HKEYS command to supported commands

2021-01-27 Thread Helena Bales (Jira)
Helena Bales created GEODE-8881:
---

 Summary: Redis: move HKEYS command to supported commands
 Key: GEODE-8881
 URL: https://issues.apache.org/jira/browse/GEODE-8881
 Project: Geode
  Issue Type: Test
  Components: redis
Reporter: Helena Bales


Write unit/integration tests that run against both Geode Redis and native 
Redis, and dunit tests which test multiple concurrent clients accessing 
different servers for the following command:

HKEYS

A.C.

Unit/integration tests for both Geode and native Redis passing
DUNIT tests passing
README/redis_api_for_geode.html.md.erb updated to make command "supported"
or
Stories in the backlog to fix the identified issues (with JIRA tickets) and 
problem tests ignored



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


[jira] [Resolved] (GEODE-8867) Unit/Integration/multi-node concurrency (Dunit) tests for **HLEN** command

2021-01-27 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-8867.
-
Resolution: Fixed

> Unit/Integration/multi-node concurrency (Dunit) tests for **HLEN** command
> --
>
> Key: GEODE-8867
> URL: https://issues.apache.org/jira/browse/GEODE-8867
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
>
> Write unit and integration tests.
> Write dunit tests, to launch multi-node clusters, which test multiple 
> concurrent clients accessing different servers for the following command:
> HLEN
> A.C.
> Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
> make command "supported", or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Created] (GEODE-8879) Redis: add unknown command response for internal commands

2021-01-27 Thread Helena Bales (Jira)
Helena Bales created GEODE-8879:
---

 Summary: Redis: add unknown command response for internal commands
 Key: GEODE-8879
 URL: https://issues.apache.org/jira/browse/GEODE-8879
 Project: Geode
  Issue Type: Improvement
  Components: redis
Reporter: Helena Bales


We have several of 'internal' commands that are not intended to be executed by 
users. When a user does execute one of these commands the server throws a NPE 
and the response is: `ERR The server had an internal error please try again`.

The reponse should be the normal `ERR unknown command ''...`



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


[jira] [Assigned] (GEODE-8867) Unit/Integration/multi-node concurrency (Dunit) tests for **HLEN** command

2021-01-21 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8867:
---

Assignee: Helena Bales

> Unit/Integration/multi-node concurrency (Dunit) tests for **HLEN** command
> --
>
> Key: GEODE-8867
> URL: https://issues.apache.org/jira/browse/GEODE-8867
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Write unit and integration tests.
> Write dunit tests, to launch multi-node clusters, which test multiple 
> concurrent clients accessing different servers for the following command:
> HLEN
> A.C.
> Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
> make command "supported", or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Created] (GEODE-8867) Unit/Integration/multi-node concurrency (Dunit) tests for **HLEN** command

2021-01-21 Thread Helena Bales (Jira)
Helena Bales created GEODE-8867:
---

 Summary: Unit/Integration/multi-node concurrency (Dunit) tests for 
**HLEN** command
 Key: GEODE-8867
 URL: https://issues.apache.org/jira/browse/GEODE-8867
 Project: Geode
  Issue Type: Test
  Components: redis
Reporter: Helena Bales


Write unit and integration tests.
Write dunit tests, to launch multi-node clusters, which test multiple 
concurrent clients accessing different servers for the following command:

HLEN

A.C.

Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
make command "supported", or
Stories in the backlog to fix the identified issues (with JIRA tickets) and 
problem tests ignored





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


[jira] [Assigned] (GEODE-8863) Redis: test hsetnx concurrency

2021-01-21 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8863:
---

Assignee: Helena Bales

> Redis: test hsetnx concurrency 
> ---
>
> Key: GEODE-8863
> URL: https://issues.apache.org/jira/browse/GEODE-8863
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
>
> Write dunit tests, to launch multi-node clusters, which test multiple 
> concurrent clients accessing different servers for the following command:
> HSETNX
> A.C.
> Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
> make command "supported", or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Updated] (GEODE-8863) Redis: test hsetnx concurrency

2021-01-21 Thread Helena Bales (Jira)


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

Helena Bales updated GEODE-8863:

Component/s: redis

> Redis: test hsetnx concurrency 
> ---
>
> Key: GEODE-8863
> URL: https://issues.apache.org/jira/browse/GEODE-8863
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Helena Bales
>Priority: Major
>
> Write dunit tests, to launch multi-node clusters, which test multiple 
> concurrent clients accessing different servers for the following command:
> HSETNX
> A.C.
> Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
> make command "supported", or
> Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Created] (GEODE-8863) Redis: test hsetnx concurrency

2021-01-21 Thread Helena Bales (Jira)
Helena Bales created GEODE-8863:
---

 Summary: Redis: test hsetnx concurrency 
 Key: GEODE-8863
 URL: https://issues.apache.org/jira/browse/GEODE-8863
 Project: Geode
  Issue Type: Test
Reporter: Helena Bales


Write dunit tests, to launch multi-node clusters, which test multiple 
concurrent clients accessing different servers for the following command:
HSETNX

A.C.
Tests are passing, and README/redis_api_for_geode.html.md.erb updated to 
make command "supported", or
Stories in the backlog to fix the identified issues (with JIRA tickets) and 
problem tests ignored



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


[jira] [Created] (GEODE-8860) Performance degradation in 1.13.0 gets and getAll

2021-01-21 Thread Helena Bales (Jira)
Helena Bales created GEODE-8860:
---

 Summary: Performance degradation in 1.13.0 gets and getAll
 Key: GEODE-8860
 URL: https://issues.apache.org/jira/browse/GEODE-8860
 Project: Geode
  Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Helena Bales


A performance degradation has been measured in Geode 1.13.0. The gets and 
getAlls show a decrease in performance >5%. Find the build and/or commit where 
the degradation occurred and track down the cause. This will require access to 
dedicated hardware for performance testing as well as experience with YourKit. 
You may also need VSD.



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


[jira] [Assigned] (GEODE-8860) Performance degradation in 1.13.0 gets and getAll

2021-01-21 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8860:
---

Assignee: Raymond Ingles

> Performance degradation in 1.13.0 gets and getAll
> -
>
> Key: GEODE-8860
> URL: https://issues.apache.org/jira/browse/GEODE-8860
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Helena Bales
>Assignee: Raymond Ingles
>Priority: Major
>
> A performance degradation has been measured in Geode 1.13.0. The gets and 
> getAlls show a decrease in performance >5%. Find the build and/or commit 
> where the degradation occurred and track down the cause. This will require 
> access to dedicated hardware for performance testing as well as experience 
> with YourKit. You may also need VSD.



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


[jira] [Created] (GEODE-8855) Redis Integration Test: add tests for all commands to redisStatsIntegrationTest

2021-01-20 Thread Helena Bales (Jira)
Helena Bales created GEODE-8855:
---

 Summary: Redis Integration Test: add tests for all commands to 
redisStatsIntegrationTest
 Key: GEODE-8855
 URL: https://issues.apache.org/jira/browse/GEODE-8855
 Project: Geode
  Issue Type: Test
  Components: redis
Reporter: Helena Bales


add tests for the unsupported commands and the rest of the untested commands. 
organize the tests. make the tests run against redis and native redis. remove 
duplicate tests from the hitsmisses test.



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


[jira] [Resolved] (GEODE-8786) INFO command hit/miss ratios should match native Redis

2021-01-11 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-8786.
-
Fix Version/s: 1.14.0
   Resolution: Fixed

> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.14.0
>
>
> Current hit/miss ratios for Geode Redis stats do not match those for native 
> Redis.



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


[jira] [Assigned] (GEODE-8786) INFO command hit/miss ratios should match native Redis

2021-01-11 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8786:
---

Assignee: Helena Bales

> INFO command hit/miss ratios should match native Redis
> --
>
> Key: GEODE-8786
> URL: https://issues.apache.org/jira/browse/GEODE-8786
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
>
> Current hit/miss ratios for Geode Redis stats do not match those for native 
> Redis.



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


[jira] [Updated] (GEODE-8709) ReplicatedFunctionExecutionBenchmark failing

2020-12-16 Thread Helena Bales (Jira)


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

Helena Bales updated GEODE-8709:

Component/s: benchmarks

> ReplicatedFunctionExecutionBenchmark failing 
> -
>
> Key: GEODE-8709
> URL: https://issues.apache.org/jira/browse/GEODE-8709
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Reporter: John Hutchison
>Priority: Major
>  Labels: benchmark
>
>  
>  
> org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionWithFiltersBenchmark
>  
>  average ops/second Baseline: 546625.03 Test: 537316.10 Difference: -1.7% 
>  ops/second standard error Baseline: 776.77 Test: 709.95 Difference: -8.6%
> s/second standard deviation Baseline: 13431.54 Test: 12276.10 Difference: 
> -8.6%
>  YS 99th percentile latency Baseline: 1700.00 Test: 1750.00 Difference: +2.9%
>  median latency Baseline: 1213439.00 Test: 1215487.00 Difference: +0.2%
>  90th percentile latency Baseline: 1465343.00 Test: 1518591.00 Difference: 
> +3.6%
>  99th percentile latency Baseline: 4517887.00 Test: 4636671.00 Difference: 
> +2.6%
>  99.9th percentile latency Baseline: 18202623.00 Test: 19234815.00 
> Difference: +5.7%
>  average latency Baseline: 1315053.32 Test: 1337898.07 Difference: +1.7%
>  latency standard deviation Baseline: 1303983.91 Test: 1335112.23 Difference: 
> +2.4%
>  latency standard error Baseline: 101.85 Test: 105.17 Difference: +3.3%
>  average ops/second Baseline: 546531.56 Test: 537283.96 Difference: -1.7%
> BENCHMARK FAILED: 
> org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionBenchmark average 
> latency is 5% worse than baseline.



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


[jira] [Updated] (GEODE-8709) ReplicatedFunctionExecutionBenchmark failing

2020-12-16 Thread Helena Bales (Jira)


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

Helena Bales updated GEODE-8709:

Labels: benchmark  (was: )

> ReplicatedFunctionExecutionBenchmark failing 
> -
>
> Key: GEODE-8709
> URL: https://issues.apache.org/jira/browse/GEODE-8709
> Project: Geode
>  Issue Type: Bug
>Reporter: John Hutchison
>Priority: Major
>  Labels: benchmark
>
>  
>  
> org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionWithFiltersBenchmark
>  
>  average ops/second Baseline: 546625.03 Test: 537316.10 Difference: -1.7% 
>  ops/second standard error Baseline: 776.77 Test: 709.95 Difference: -8.6%
> s/second standard deviation Baseline: 13431.54 Test: 12276.10 Difference: 
> -8.6%
>  YS 99th percentile latency Baseline: 1700.00 Test: 1750.00 Difference: +2.9%
>  median latency Baseline: 1213439.00 Test: 1215487.00 Difference: +0.2%
>  90th percentile latency Baseline: 1465343.00 Test: 1518591.00 Difference: 
> +3.6%
>  99th percentile latency Baseline: 4517887.00 Test: 4636671.00 Difference: 
> +2.6%
>  99.9th percentile latency Baseline: 18202623.00 Test: 19234815.00 
> Difference: +5.7%
>  average latency Baseline: 1315053.32 Test: 1337898.07 Difference: +1.7%
>  latency standard deviation Baseline: 1303983.91 Test: 1335112.23 Difference: 
> +2.4%
>  latency standard error Baseline: 101.85 Test: 105.17 Difference: +3.3%
>  average ops/second Baseline: 546531.56 Test: 537283.96 Difference: -1.7%
> BENCHMARK FAILED: 
> org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionBenchmark average 
> latency is 5% worse than baseline.



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


[jira] [Created] (GEODE-8763) Benchmark CI only runs tests 4 times

2020-12-02 Thread Helena Bales (Jira)
Helena Bales created GEODE-8763:
---

 Summary: Benchmark CI only runs tests 4 times
 Key: GEODE-8763
 URL: https://issues.apache.org/jira/browse/GEODE-8763
 Project: Geode
  Issue Type: Bug
  Components: benchmarks, ci
Reporter: Helena Bales


The benchmark has a retry mechanism that is supposed to run all tests, then 
rerun any failed tests. If tests are still failing then it should retry those 
tests, for a total of 5 test runs (including the first run of all the tests). 
Currently it only runs the tests a total of 4 times.

Increase the number of runs to 5 to increase the tolerance for variance in 
tests.



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


[jira] [Assigned] (GEODE-8763) Benchmark CI only runs tests 4 times

2020-12-02 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8763:
---

Assignee: Helena Bales

> Benchmark CI only runs tests 4 times
> 
>
> Key: GEODE-8763
> URL: https://issues.apache.org/jira/browse/GEODE-8763
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks, ci
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> The benchmark has a retry mechanism that is supposed to run all tests, then 
> rerun any failed tests. If tests are still failing then it should retry those 
> tests, for a total of 5 test runs (including the first run of all the tests). 
> Currently it only runs the tests a total of 4 times.
> Increase the number of runs to 5 to increase the tolerance for variance in 
> tests.



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


[jira] [Created] (GEODE-8662) Test the STRLEN redis command

2020-10-27 Thread Helena Bales (Jira)
Helena Bales created GEODE-8662:
---

 Summary: Test the STRLEN redis command
 Key: GEODE-8662
 URL: https://issues.apache.org/jira/browse/GEODE-8662
 Project: Geode
  Issue Type: Improvement
  Components: redis
Reporter: Helena Bales


Confirm the existence of or add tests for the Redis STRLEN command, ensuring 
they cover all documented behaviors and match the style of existing tests.

Acceptance Criteria:
- NativeRedisAcceptanceTest file present to run our tests against native 
Redis
- Tests are passing, or
- Stories in the backlog to fix the identified issues (with JIRA tickets) 
and problem tests ignored




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


[jira] [Assigned] (GEODE-8662) Test the STRLEN redis command

2020-10-27 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-8662:
---

Assignee: Helena Bales

> Test the STRLEN redis command
> -
>
> Key: GEODE-8662
> URL: https://issues.apache.org/jira/browse/GEODE-8662
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Confirm the existence of or add tests for the Redis STRLEN command, ensuring 
> they cover all documented behaviors and match the style of existing tests.
> Acceptance Criteria:
> - NativeRedisAcceptanceTest file present to run our tests against native 
> Redis
> - Tests are passing, or
> - Stories in the backlog to fix the identified issues (with JIRA tickets) 
> and problem tests ignored



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


[jira] [Resolved] (GEODE-7068) Benchmark CI: Update baseline used on develop

2020-09-17 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7068.
-
Resolution: Not A Problem

out of date task.

> Benchmark CI: Update baseline used on develop
> -
>
> Key: GEODE-7068
> URL: https://issues.apache.org/jira/browse/GEODE-7068
> Project: Geode
>  Issue Type: Task
>Reporter: Helena Bales
>Priority: Major
>  Labels: performance
>
> Once the next version of Geode has been released, changes to develop should 
> be benchmarked against the released version 1.10.0.



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


[jira] [Resolved] (GEODE-7581) Benchmark CI: run SSL tests with JDK11

2020-01-02 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7581.
-
Resolution: Fixed

> Benchmark CI: run SSL tests with JDK11
> --
>
> Key: GEODE-7581
> URL: https://issues.apache.org/jira/browse/GEODE-7581
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Run the SSL benchmarks in CI with JDK 11 to improve their stability.



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


[jira] [Resolved] (GEODE-7422) ReplicatedGetBenchmark with SSL is failing intermittently

2020-01-02 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7422.
-
Resolution: Not A Problem

> ReplicatedGetBenchmark with SSL is failing intermittently
> -
>
> Key: GEODE-7422
> URL: https://issues.apache.org/jira/browse/GEODE-7422
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Reporter: Jacob Barrett
>Assignee: Helena Bales
>Priority: Major
>
> org.apache.geode.benchmark.tests.ReplicatedGetBenchmark fails intermittently 
> with SSL enabled. The put and get benchmarks show consistently lower 
> performance with SSL enabled between high-water mark and HEAD of develop.
> Current high-water: 42a0d0d54d5e307837d0b12d87bb288ac7c2493e
> Current HEAD: cf1aef105853df4455fc19301aa233a99443071d
>  
>  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/671#L5dbce136:1874]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/643#L5d980631:1872]
>  



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


[jira] [Resolved] (GEODE-7554) Benchmark CI: rerun failed tests

2019-12-30 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7554.
-
Fix Version/s: 1.11.0
   Resolution: Fixed

> Benchmark CI: rerun failed tests
> 
>
> Key: GEODE-7554
> URL: https://issues.apache.org/jira/browse/GEODE-7554
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> When tests run in CI fail, they will be written to a file. Read that file and 
> rerun the failed tests until the list is empty, or until the run has been 
> retried 5 times. Any tests that fail 5 times in a row are not flaky and need 
> to be addressed.



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


[jira] [Assigned] (GEODE-7422) ReplicatedGetBenchmark with SSL is failing intermittently

2019-12-19 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-7422:
---

Assignee: Helena Bales

> ReplicatedGetBenchmark with SSL is failing intermittently
> -
>
> Key: GEODE-7422
> URL: https://issues.apache.org/jira/browse/GEODE-7422
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Reporter: Jacob Barrett
>Assignee: Helena Bales
>Priority: Major
>
> org.apache.geode.benchmark.tests.ReplicatedGetBenchmark fails intermittently 
> with SSL enabled. The put and get benchmarks show consistently lower 
> performance with SSL enabled between high-water mark and HEAD of develop.
> Current high-water: 42a0d0d54d5e307837d0b12d87bb288ac7c2493e
> Current HEAD: cf1aef105853df4455fc19301aa233a99443071d
>  
>  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/671#L5dbce136:1874]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/643#L5d980631:1872]
>  



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


[jira] [Resolved] (GEODE-7054) Add some SSL benchmarks to CI

2019-12-19 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7054.
-
Fix Version/s: 1.11.0
   Resolution: Fixed

> Add some SSL benchmarks to CI
> -
>
> Key: GEODE-7054
> URL: https://issues.apache.org/jira/browse/GEODE-7054
> Project: Geode
>  Issue Type: Improvement
>Reporter: Murtuza Boxwala
>Assignee: Murtuza Boxwala
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Add task for running some benchmarks with SSL enabled. This task should run 
> in parallel with the current benchmark task. Should run targeted benchmarks.
> Benchmarks:
>  * *GetBenchmark
>  * *PutBenchmark
> Args:
> -PwithSsl
> Accpetance:
> Benchmarks are stable between runs and don't cause numerous false failures. 
> May require adding story for adding parameter analyzer to specify alternative 
> threshold (default is 5%).



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


[jira] [Created] (GEODE-7581) Benchmark CI: run SSL tests with JDK11

2019-12-13 Thread Helena Bales (Jira)
Helena Bales created GEODE-7581:
---

 Summary: Benchmark CI: run SSL tests with JDK11
 Key: GEODE-7581
 URL: https://issues.apache.org/jira/browse/GEODE-7581
 Project: Geode
  Issue Type: Improvement
  Components: benchmarks
Reporter: Helena Bales


Run the SSL benchmarks in CI with JDK 11 to improve their stability.



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


[jira] [Assigned] (GEODE-7581) Benchmark CI: run SSL tests with JDK11

2019-12-13 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-7581:
---

Assignee: Helena Bales

> Benchmark CI: run SSL tests with JDK11
> --
>
> Key: GEODE-7581
> URL: https://issues.apache.org/jira/browse/GEODE-7581
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Run the SSL benchmarks in CI with JDK 11 to improve their stability.



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


[jira] [Assigned] (GEODE-7554) Benchmark CI: rerun failed tests

2019-12-05 Thread Helena Bales (Jira)


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

Helena Bales reassigned GEODE-7554:
---

Assignee: Helena Bales

> Benchmark CI: rerun failed tests
> 
>
> Key: GEODE-7554
> URL: https://issues.apache.org/jira/browse/GEODE-7554
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> When tests run in CI fail, they will be written to a file. Read that file and 
> rerun the failed tests until the list is empty, or until the run has been 
> retried 5 times. Any tests that fail 5 times in a row are not flaky and need 
> to be addressed.



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


[jira] [Created] (GEODE-7554) Benchmark CI: rerun failed tests

2019-12-05 Thread Helena Bales (Jira)
Helena Bales created GEODE-7554:
---

 Summary: Benchmark CI: rerun failed tests
 Key: GEODE-7554
 URL: https://issues.apache.org/jira/browse/GEODE-7554
 Project: Geode
  Issue Type: Improvement
  Components: benchmarks
Reporter: Helena Bales


When tests run in CI fail, they will be written to a file. Read that file and 
rerun the failed tests until the list is empty, or until the run has been 
retried 5 times. Any tests that fail 5 times in a row are not flaky and need to 
be addressed.



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


[jira] [Resolved] (GEODE-7014) Add Benchmark task to main tab of CI

2019-09-10 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7014.
-
Fix Version/s: 1.9.0
   Resolution: Fixed

> Add Benchmark task to main tab of CI
> 
>
> Key: GEODE-7014
> URL: https://issues.apache.org/jira/browse/GEODE-7014
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks, ci
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.9.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Benchmarks are now relatively stable, so they should be added to the main tab 
> of CI and monitored for failures.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Resolved] (GEODE-7067) Release CI tests wrong branch in benchmark

2019-09-10 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7067.
-
Resolution: Not A Problem

> Release CI tests wrong branch in benchmark
> --
>
> Key: GEODE-7067
> URL: https://issues.apache.org/jira/browse/GEODE-7067
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance
> Fix For: 1.10.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The branch tested in the 1.10.0 release pipeline is still pointing at 
> develop, and should be updated to point at apache/geode:release/1.10.0.
> The release branch should be compared to the most recent high watermark. This 
> is because the performance of the previous release is significantly lower 
> than when the 1.10.0 release branch was cut. In order to detect any 
> degradations in performance that have occurred since the release branch was 
> cut, we should compare the current release candidate with the commit 
> previously determined to be the stable best performance achieved by Geode, in 
> all tests, since the previous release. This was a commit on develop, prior to 
> where the 1.10.0 release branch was cut, and is marked by the tag 
> develop/highwater.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Resolved] (GEODE-6898) CI: Benchmark job should be called with --ci option

2019-09-10 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-6898.
-
Fix Version/s: 1.9.0
   Resolution: Fixed

> CI: Benchmark job should be called with --ci option
> ---
>
> Key: GEODE-6898
> URL: https://issues.apache.org/jira/browse/GEODE-6898
> Project: Geode
>  Issue Type: New Feature
>  Components: benchmarks
>Reporter: Kamilla Aslami
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.9.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The benchmark CI job should be called with the --ci option to indicate to the 
> benchmark that the caller is a CI pipeline. This work is related to a PR on 
> the geode-benchmark repo: [https://github.com/apache/geode-benchmarks/pull/86]



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Updated] (GEODE-7068) Benchmark CI: Update baseline used on develop

2019-08-09 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-7068:

Labels: performance  (was: )

> Benchmark CI: Update baseline used on develop
> -
>
> Key: GEODE-7068
> URL: https://issues.apache.org/jira/browse/GEODE-7068
> Project: Geode
>  Issue Type: Task
>Reporter: Helena Bales
>Priority: Major
>  Labels: performance
>
> Once the next version of Geode has been released, changes to develop should 
> be benchmarked against the released version 1.10.0.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (GEODE-7068) Benchmark CI: Update baseline used on develop

2019-08-09 Thread Helena Bales (JIRA)
Helena Bales created GEODE-7068:
---

 Summary: Benchmark CI: Update baseline used on develop
 Key: GEODE-7068
 URL: https://issues.apache.org/jira/browse/GEODE-7068
 Project: Geode
  Issue Type: Task
Reporter: Helena Bales


Once the next version of Geode has been released, changes to develop should be 
benchmarked against the released version 1.10.0.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (GEODE-7067) Release CI tests wrong branch in benchmark

2019-08-09 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-7067:

Labels: performance  (was: )

> Release CI tests wrong branch in benchmark
> --
>
> Key: GEODE-7067
> URL: https://issues.apache.org/jira/browse/GEODE-7067
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance
> Fix For: 1.10.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The branch tested in the 1.10.0 release pipeline is still pointing at 
> develop, and should be updated to point at apache/geode:release/1.10.0.
> The release branch should be compared to the most recent high watermark. This 
> is because the performance of the previous release is significantly lower 
> than when the 1.10.0 release branch was cut. In order to detect any 
> degradations in performance that have occurred since the release branch was 
> cut, we should compare the current release candidate with the commit 
> previously determined to be the stable best performance achieved by Geode, in 
> all tests, since the previous release. This was a commit on develop, prior to 
> where the 1.10.0 release branch was cut, and is marked by the tag 
> develop/highwater.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (GEODE-7067) Release CI tests wrong branch in benchmark

2019-08-09 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-7067:
---

Assignee: Helena Bales

> Release CI tests wrong branch in benchmark
> --
>
> Key: GEODE-7067
> URL: https://issues.apache.org/jira/browse/GEODE-7067
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The branch tested in the 1.10.0 release pipeline is still pointing at 
> develop, and should be updated to point at apache/geode:release/1.10.0.
> The release branch should be compared to the most recent high watermark. This 
> is because the performance of the previous release is significantly lower 
> than when the 1.10.0 release branch was cut. In order to detect any 
> degradations in performance that have occurred since the release branch was 
> cut, we should compare the current release candidate with the commit 
> previously determined to be the stable best performance achieved by Geode, in 
> all tests, since the previous release. This was a commit on develop, prior to 
> where the 1.10.0 release branch was cut, and is marked by the tag 
> develop/highwater.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (GEODE-7067) Release CI tests wrong branch in benchmark

2019-08-09 Thread Helena Bales (JIRA)
Helena Bales created GEODE-7067:
---

 Summary: Release CI tests wrong branch in benchmark
 Key: GEODE-7067
 URL: https://issues.apache.org/jira/browse/GEODE-7067
 Project: Geode
  Issue Type: Bug
Reporter: Helena Bales
 Fix For: 1.10.0


The branch tested in the 1.10.0 release pipeline is still pointing at develop, 
and should be updated to point at apache/geode:release/1.10.0.

The release branch should be compared to the most recent high watermark. This 
is because the performance of the previous release is significantly lower than 
when the 1.10.0 release branch was cut. In order to detect any degradations in 
performance that have occurred since the release branch was cut, we should 
compare the current release candidate with the commit previously determined to 
be the stable best performance achieved by Geode, in all tests, since the 
previous release. This was a commit on develop, prior to where the 1.10.0 
release branch was cut, and is marked by the tag develop/highwater.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (GEODE-7059) CI Failure: Tomcat8ClientServerRollingUpgradeTest.canDoARollingUpgradeOfGeodeServersWithSessionModules[170]

2019-08-07 Thread Helena Bales (JIRA)
Helena Bales created GEODE-7059:
---

 Summary: CI Failure: 
Tomcat8ClientServerRollingUpgradeTest.canDoARollingUpgradeOfGeodeServersWithSessionModules[170]
 Key: GEODE-7059
 URL: https://issues.apache.org/jira/browse/GEODE-7059
 Project: Geode
  Issue Type: Bug
Reporter: Helena Bales


Tomcat8ClientServerRollingUpgradeTest failed in CI: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/954
Results available here: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0008/test-results/upgradeTest/1565134781/
Archive here: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0008/test-artifacts/1565134781/upgradetestfiles-OpenJDK8-1.11.0-SNAPSHOT.0008.tgz

The issue appears to be a port conflict, however a connection through GFSH does 
not seem like it should be triggering JMX startup.

{noformat}
Executing db801bc9548a20f6: gfsh -e connect --locator=localhost[25018] -e 
create region --type=PARTITION_REDUNDANT --name=gemfire_modules_sessions 
--enable-statistics=true 
--entry-idle-time-custom-expiry=org.apache.geode.modules.util.SessionCustomExpiry
[INFO  23:03:02.978 GMT] (db801bc9548a20f6): 
[INFO  23:03:02.978 GMT] (db801bc9548a20f6): (1) Executing - connect 
--locator=localhost[25018]
[INFO  23:03:02.979 GMT] (db801bc9548a20f6): 
[INFO  23:03:03.017 GMT] (db801bc9548a20f6): Connecting to Locator at 
[host=localhost, port=25018] ..
[ERROR 23:03:05.075 GMT] (db801bc9548a20f6): Exception caused JMX Manager 
startup to fail because: 'java.rmi.server.ExportException: Port already in use: 
25019; nested exception is: 
[ERROR 23:03:05.075 GMT] (db801bc9548a20f6): java.net.BindException: Failed 
to create server socket on  null[25,019]'
{noformat}




--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (GEODE-7014) Add Benchmark task to main tab of CI

2019-07-25 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-7014:
---

Assignee: Helena Bales

> Add Benchmark task to main tab of CI
> 
>
> Key: GEODE-7014
> URL: https://issues.apache.org/jira/browse/GEODE-7014
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks, ci
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Benchmarks are now relatively stable, so they should be added to the main tab 
> of CI and monitored for failures.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Created] (GEODE-7014) Add Benchmark task to main tab of CI

2019-07-25 Thread Helena Bales (JIRA)
Helena Bales created GEODE-7014:
---

 Summary: Add Benchmark task to main tab of CI
 Key: GEODE-7014
 URL: https://issues.apache.org/jira/browse/GEODE-7014
 Project: Geode
  Issue Type: Improvement
  Components: benchmarks, ci
Reporter: Helena Bales


Benchmarks are now relatively stable, so they should be added to the main tab 
of CI and monitored for failures.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks

2019-07-16 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6827.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Benchmark CI: Make Windows jobs not gating for benchmarks
> -
>
> Key: GEODE-6827
> URL: https://issues.apache.org/jira/browse/GEODE-6827
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
> Fix For: 1.10.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> In Geode CI, the Benchmark job is blocked by the successful completion of the 
> Windows tests. Since Benchmark runs on linux and the Windows tests still 
> frequently fail with timing issues, it does not make sense for these tests to 
> be gating to Benchmark runs. When they are gating, we do not get frequent 
> runs of the benchmark task.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Resolved] (GEODE-4806) Replace SimpleTestSecurityManager with SimpleSecurityManager

2019-07-16 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-4806.
-
Resolution: Fixed

Resolved by linked PR; forgot to close when merging

> Replace SimpleTestSecurityManager with SimpleSecurityManager
> 
>
> Key: GEODE-4806
> URL: https://issues.apache.org/jira/browse/GEODE-4806
> Project: Geode
>  Issue Type: Task
>  Components: security
>Reporter: Jens Deppe
>Assignee: Sean Goller
>Priority: Major
>  Labels: starter
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> These classes appear to be the same. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (GEODE-6636) Buffers.acquireBuffer is not optimal

2019-06-28 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6636:
---

Assignee: (was: Helena Bales)

> Buffers.acquireBuffer is not optimal
> 
>
> Key: GEODE-6636
> URL: https://issues.apache.org/jira/browse/GEODE-6636
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Priority: Major
>  Labels: performance
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a 
> ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the 
> queue and adds it to an IdentityHashMap. The map is just to detect if we have 
> looped around and found one we added to the map in a previous iteration.
> A more efficient way to do this, which will only remove things from the queue 
> that we will either throw away or use and return later, and which gets rid of 
> the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an 
> example of this by looking at: 
> AvailableConnectionManager.EqualsWithPredicate. The predicate to use with 
> acquireBuffer is that the soft reference is null or that the capacity of the 
> referenced buffer is large enough. If you remove one because the reference is 
> null then you need to call remove(Object) again (after decrementing the 
> correct stat) since all you did was find one that had been garbage collected. 
> You want to keep the predicate as cheap as possible since it is called in the 
> "compare-and-set" spin loop. The more you do in the predicate, the more 
> likely a concurrent thread will take that buffer and you will need to spin 
> around and try again.
> I was surprised when running a benchmark under the profiler to see operations 
> on this IdentityHashMap show up. The benchmark was doing pr puts of all the 
> same size so I would have thought all these direct buffers would be the same. 
> I think it would be worth understanding what sizes of buffers will be 
> requested by acquireBuffer and how often they will be acquired and returned. 
> If different sizes is a normal use case then it probably would make sense to 
> have more than one queue. If we could go to a queue knowing that if it has a 
> buffer in it that it meets are desired size. The geode off-heap free list 
> implementation does this and only the largest allocations need to search 
> through a free list that has items in it that exceed a max size. Every other 
> free list is found quickly be using the requested size to index an array of 
> free lists, which only contain items of that size.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-6636) Buffers.acquireBuffer is not optimal

2019-06-28 Thread Helena Bales (JIRA)


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

Helena Bales commented on GEODE-6636:
-

Completing this refactor will take more effort than we initially expected. It 
may be better to refactor the way the buffer pool works as a whole.

In the current implementation, a buffer is polled from the head of the queue. 
It gets used if it is a big enough buffer. If it isn't big enough, it gets put 
to a set. If the put fails, then we have already checked that buffer and have 
therefore looped through all the buffers without finding one that is big 
enough. If we have checked all the buffers and didn't find one to use, then we 
create a new one.
This implementation creates a lot of garbage, and is not very thread safe.

In the implementation proposed by [this 
PR|https://github.com/apache/geode/pull/3741], an iterator is created for the 
buffer pool. The item at the head of the iterator is removed, and is used if it 
is big enough. If it is too small, the buffer is replaced on the head of the 
dequeue, and the iterator will move to point to the next item (Note: the 
movement of the iterator to the next item can't be relied upon if there is 
concurrent access to the dequeue, so we can't make this assumption). If we 
reach the end of the dequeue without finding a buffer that is big enough, then 
we will have to create one.
This implementation creates less garbage than the previous implementation, but 
is no better in speed, and no more thread safe than the previous implementation.

> Buffers.acquireBuffer is not optimal
> 
>
> Key: GEODE-6636
> URL: https://issues.apache.org/jira/browse/GEODE-6636
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a 
> ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the 
> queue and adds it to an IdentityHashMap. The map is just to detect if we have 
> looped around and found one we added to the map in a previous iteration.
> A more efficient way to do this, which will only remove things from the queue 
> that we will either throw away or use and return later, and which gets rid of 
> the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an 
> example of this by looking at: 
> AvailableConnectionManager.EqualsWithPredicate. The predicate to use with 
> acquireBuffer is that the soft reference is null or that the capacity of the 
> referenced buffer is large enough. If you remove one because the reference is 
> null then you need to call remove(Object) again (after decrementing the 
> correct stat) since all you did was find one that had been garbage collected. 
> You want to keep the predicate as cheap as possible since it is called in the 
> "compare-and-set" spin loop. The more you do in the predicate, the more 
> likely a concurrent thread will take that buffer and you will need to spin 
> around and try again.
> I was surprised when running a benchmark under the profiler to see operations 
> on this IdentityHashMap show up. The benchmark was doing pr puts of all the 
> same size so I would have thought all these direct buffers would be the same. 
> I think it would be worth understanding what sizes of buffers will be 
> requested by acquireBuffer and how often they will be acquired and returned. 
> If different sizes is a normal use case then it probably would make sense to 
> have more than one queue. If we could go to a queue knowing that if it has a 
> buffer in it that it meets are desired size. The geode off-heap free list 
> implementation does this and only the largest allocations need to search 
> through a free list that has items in it that exceed a max size. Every other 
> free list is found quickly be using the requested size to index an array of 
> free lists, which only contain items of that size.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6636) Buffers.acquireBuffer is not optimal

2019-06-21 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6636:
---

Assignee: Helena Bales

> Buffers.acquireBuffer is not optimal
> 
>
> Key: GEODE-6636
> URL: https://issues.apache.org/jira/browse/GEODE-6636
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Darrel Schneider
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance
>
> org.apache.geode.internal.net.Buffers.acquireBuffer takes buffers out of a 
> ConcurrentLinkedQueue. If the buffer is too small then it adds it back to the 
> queue and adds it to an IdentityHashMap. The map is just to detect if we have 
> looped around and found one we added to the map in a previous iteration.
> A more efficient way to do this, which will only remove things from the queue 
> that we will either throw away or use and return later, and which gets rid of 
> the map, is to use ConcurrentLinkedQueue.remove(Object). You can see an 
> example of this by looking at: 
> AvailableConnectionManager.EqualsWithPredicate. The predicate to use with 
> acquireBuffer is that the soft reference is null or that the capacity of the 
> referenced buffer is large enough. If you remove one because the reference is 
> null then you need to call remove(Object) again (after decrementing the 
> correct stat) since all you did was find one that had been garbage collected. 
> You want to keep the predicate as cheap as possible since it is called in the 
> "compare-and-set" spin loop. The more you do in the predicate, the more 
> likely a concurrent thread will take that buffer and you will need to spin 
> around and try again.
> I was surprised when running a benchmark under the profiler to see operations 
> on this IdentityHashMap show up. The benchmark was doing pr puts of all the 
> same size so I would have thought all these direct buffers would be the same. 
> I think it would be worth understanding what sizes of buffers will be 
> requested by acquireBuffer and how often they will be acquired and returned. 
> If different sizes is a normal use case then it probably would make sense to 
> have more than one queue. If we could go to a queue knowing that if it has a 
> buffer in it that it meets are desired size. The geode off-heap free list 
> implementation does this and only the largest allocations need to search 
> through a free list that has items in it that exceed a max size. Every other 
> free list is found quickly be using the requested size to index an array of 
> free lists, which only contain items of that size.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6898) CI: Benchmark job should update git tag

2019-06-20 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6898:
---

Assignee: Helena Bales

> CI: Benchmark job should update git tag
> ---
>
> Key: GEODE-6898
> URL: https://issues.apache.org/jira/browse/GEODE-6898
> Project: Geode
>  Issue Type: New Feature
>  Components: benchmarks
>Reporter: Kamilla Aslami
>Assignee: Helena Bales
>Priority: Major
>
> The benchmark CI job should have a task that updates the high watermark git 
> tag when a new commit is selected by the benchmark.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks

2019-06-04 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6827:
---

Assignee: Helena Bales

> Benchmark CI: Make Windows jobs not gating for benchmarks
> -
>
> Key: GEODE-6827
> URL: https://issues.apache.org/jira/browse/GEODE-6827
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> In Geode CI, the Benchmark job is blocked by the successful completion of the 
> Windows tests. Since Benchmark runs on linux and the Windows tests still 
> frequently fail with timing issues, it does not make sense for these tests to 
> be gating to Benchmark runs. When they are gating, we do not get frequent 
> runs of the benchmark task.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks

2019-06-04 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6827:
---

 Summary: Benchmark CI: Make Windows jobs not gating for benchmarks
 Key: GEODE-6827
 URL: https://issues.apache.org/jira/browse/GEODE-6827
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


In Geode CI, the Benchmark job is blocked by the successful completion of the 
Windows tests. Since Benchmark runs on linux and the Windows tests still 
frequently fail with timing issues, it does not make sense for these tests to 
be gating to Benchmark runs. When they are gating, we do not get frequent runs 
of the benchmark task.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6827) Benchmark CI: Make Windows jobs not gating for benchmarks

2019-06-04 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6827:

Labels: performance-benchmark  (was: )

> Benchmark CI: Make Windows jobs not gating for benchmarks
> -
>
> Key: GEODE-6827
> URL: https://issues.apache.org/jira/browse/GEODE-6827
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
>
> In Geode CI, the Benchmark job is blocked by the successful completion of the 
> Windows tests. Since Benchmark runs on linux and the Windows tests still 
> frequently fail with timing issues, it does not make sense for these tests to 
> be gating to Benchmark runs. When they are gating, we do not get frequent 
> runs of the benchmark task.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6693) CI Failure: ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently

2019-04-23 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6693.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> CI Failure: ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently
> 
>
> Key: GEODE-6693
> URL: https://issues.apache.org/jira/browse/GEODE-6693
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently fails 
> intermittently in CI with stack trace:
> {noformat}
> org.apache.geode.test.concurrency.ConcurrentTestRunnerTest > 
> confirmThatInParallelRunsConcurrently FAILED
>   
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
>   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.concurrency.ConcurrentTestRunnerTest.confirmThatInParallelRunsConcurrently(ConcurrentTestRunnerTest.java:36)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6693) CI Failure: ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently

2019-04-22 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6693:
---

Assignee: Helena Bales

> CI Failure: ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently
> 
>
> Key: GEODE-6693
> URL: https://issues.apache.org/jira/browse/GEODE-6693
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently fails 
> intermittently in CI with stack trace:
> {noformat}
> org.apache.geode.test.concurrency.ConcurrentTestRunnerTest > 
> confirmThatInParallelRunsConcurrently FAILED
>   
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
>   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.concurrency.ConcurrentTestRunnerTest.confirmThatInParallelRunsConcurrently(ConcurrentTestRunnerTest.java:36)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6693) CI Failure: ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently

2019-04-22 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6693:
---

 Summary: CI Failure: ConcurrentTestRunnerTest > 
confirmThatInParallelRunsConcurrently
 Key: GEODE-6693
 URL: https://issues.apache.org/jira/browse/GEODE-6693
 Project: Geode
  Issue Type: Bug
Reporter: Helena Bales


ConcurrentTestRunnerTest > confirmThatInParallelRunsConcurrently fails 
intermittently in CI with stack trace:

{noformat}
org.apache.geode.test.concurrency.ConcurrentTestRunnerTest > 
confirmThatInParallelRunsConcurrently FAILED

org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
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.concurrency.ConcurrentTestRunnerTest.confirmThatInParallelRunsConcurrently(ConcurrentTestRunnerTest.java:36)

{noformat}





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6582) Performance Improvement: get max message size once

2019-04-10 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6582.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Performance Improvement: get max message size once
> --
>
> Key: GEODE-6582
> URL: https://issues.apache.org/jira/browse/GEODE-6582
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
> Fix For: 1.10.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The max message size in Message.java does not change over the course of 
> runtime, and yet was being recalculated with every new message received. Make 
> this value static and only calculate it once to improve the performance of 
> messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6584) Performance Improvement: Do not synchronize on volatile variables

2019-04-10 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6584.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Performance Improvement: Do not synchronize on volatile variables
> -
>
> Key: GEODE-6584
> URL: https://issues.apache.org/jira/browse/GEODE-6584
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
> Fix For: 1.10.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> In ServerConnection, do not synchronize on volatile boolean processMessage. 
> It is not necessary and will have a negative performance impact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-5407) org.apache.geode.management.JMXMBeanReconnectDUnitTest > testRemoteBeanKnowledge_MaintainServerAndCrashLocator and testLocalBeans_MaintainServerAndCrashLocator FAILED

2019-04-10 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-5407:
---

Assignee: (was: Helena Bales)

> org.apache.geode.management.JMXMBeanReconnectDUnitTest > 
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator and 
> testLocalBeans_MaintainServerAndCrashLocator FAILED
> --
>
> Key: GEODE-5407
> URL: https://issues.apache.org/jira/browse/GEODE-5407
> Project: Geode
>  Issue Type: Bug
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: pull-request-available, swat
> Fix For: 1.9.0
>
> Attachments: Test results - Class 
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.html
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> org.apache.geode.management.JMXMBeanReconnectDUnitTest > 
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:249]
>  org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.rules.MemberVM$$Lambda$73/2140274979.run in VM 0 
> running on Host 640ab3da6905 with 4 VMs
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:250]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:251]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:252]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:253]
>  at 
> org.apache.geode.test.dunit.rules.MemberVM.waitTilLocatorFullyReconnected(MemberVM.java:113)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:254]
>  at 
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.testRemoteBeanKnowledge_MaintainServerAndCrashLocator(JMXMBeanReconnectDUnitTest.java:161)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:255]
>  
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:256]
>  Caused by:
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:257]
>  org.awaitility.core.ConditionTimeoutException: Condition with 
> org.apache.geode.test.dunit.rules.MemberVM was not fulfilled within 30 
> seconds.
>  
> org.apache.geode.management.JMXMBeanReconnectDUnitTest > 
> testLocalBeans_MaintainServerAndCrashLocator FAILED
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:260]
>  org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.rules.MemberVM$$Lambda$73/2140274979.run in VM 0 
> running on Host 640ab3da6905 with 4 VMs
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:261]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:262]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:263]
>  at org.apache.geode.test.dunit.VM.invoke(VM.java:348)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:264]
>  at 
> org.apache.geode.test.dunit.rules.MemberVM.waitTilLocatorFullyReconnected(MemberVM.java:113)
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:265]
>  at 
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainServerAndCrashLocator(JMXMBeanReconnectDUnitTest.java:112)
>  
>  Caused by:
> [ 
> |https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/103#L5b401925:268]
>  org.awaitility.core.ConditionTimeoutException: Condition with 
> org.apache.geode.test.dunit.rules.MemberVM was not fulfilled within 30 
> seconds.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6601) CI Failure: Timeout in LuceneIndexDestroyDUnitTest verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)

2019-04-04 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6601:
---

 Summary: CI Failure: Timeout in LuceneIndexDestroyDUnitTest 
verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)
 Key: GEODE-6601
 URL: https://issues.apache.org/jira/browse/GEODE-6601
 Project: Geode
  Issue Type: Bug
Reporter: Helena Bales


DistributedTestJDK11 failed due to timeout with a hang in 
org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest 
verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK).

CI Failure here: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/579
Test results here: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-results/distributedTest/1554409876/
Test artifacts here: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-artifacts/1554409876/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0137.tgz



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6577) Performance Improvement: init object in constructor

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6577.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Performance Improvement: init object in constructor
> ---
>
> Key: GEODE-6577
> URL: https://issues.apache.org/jira/browse/GEODE-6577
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
> Fix For: 1.10.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Initialize inexpensive object in the constructor for GemfireCacheImpl instead 
> of in a hot code path, while holding a lock. This will result in a noticeable 
> performance gain.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-6462) [CI Failure] LocatorConnectionDUnitTest > testGetAvailableServersWithStats failed on validateStats

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales commented on GEODE-6462:
-

Saw this exact failure again in PR pipeline.

CI run: [https://concourse.apachegeode-ci.info/builds/52750]

Artifacts: 
[http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-3378/test-results/distributedTest/1554145740/]

> [CI Failure] LocatorConnectionDUnitTest > testGetAvailableServersWithStats 
> failed on validateStats
> --
>
> Key: GEODE-6462
> URL: https://issues.apache.org/jira/browse/GEODE-6462
> Project: Geode
>  Issue Type: Test
>  Components: core
>Reporter: Jens Deppe
>Priority: Major
>  Labels: ci
>
> This seems like a flakey test.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/443]
> The test and the protobuf code has not been updated in a while. This is 
> probably a flake.
> The following is the error thread
> {code:java}
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest
>  > testGetAvailableServersWithStats FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest$$Lambda$37/842046356.run
>  in VM 0 running on Host 22c25e73171b with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:85)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.validateStats(LocatorConnectionDUnitTest.java:234)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.testSocketWithStats(LocatorConnectionDUnitTest.java:127)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.testGetAvailableServersWithStats(LocatorConnectionDUnitTest.java:106)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest
>  that uses long, longlong, longlong, longlong, longint, intint expected:<3> 
> but was:<4> within 300 seconds.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.lambda$validateStats$c7642ca0$1(LocatorConnectionDUnitTest.java:235)
> Caused by:
> java.lang.AssertionError: expected:<3> but was:<4>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.lambda$null$0(LocatorConnectionDUnitTest.java:238)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0487/test-results/distributedTest/1551228892/]
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0487/test-artifacts/1551228892/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0487.tgz]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6584) Performance Improvement: Do not synchronize on volatile variables

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6584:

Labels: performance-benchmark  (was: )

> Performance Improvement: Do not synchronize on volatile variables
> -
>
> Key: GEODE-6584
> URL: https://issues.apache.org/jira/browse/GEODE-6584
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
>
> In ServerConnection, do not synchronize on volatile boolean processMessage. 
> It is not necessary and will have a negative performance impact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6584) Performance Improvement: Do not synchronize on volatile variables

2019-04-01 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6584:
---

 Summary: Performance Improvement: Do not synchronize on volatile 
variables
 Key: GEODE-6584
 URL: https://issues.apache.org/jira/browse/GEODE-6584
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


In ServerConnection, do not synchronize on volatile boolean processMessage. It 
is not necessary and will have a negative performance impact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6584) Performance Improvement: Do not synchronize on volatile variables

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6584:
---

Assignee: Helena Bales

> Performance Improvement: Do not synchronize on volatile variables
> -
>
> Key: GEODE-6584
> URL: https://issues.apache.org/jira/browse/GEODE-6584
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> In ServerConnection, do not synchronize on volatile boolean processMessage. 
> It is not necessary and will have a negative performance impact.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6582) Performance Improvement: get max message size once

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6582:

Labels: performance-benchmark  (was: )

> Performance Improvement: get max message size once
> --
>
> Key: GEODE-6582
> URL: https://issues.apache.org/jira/browse/GEODE-6582
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
>
> The max message size in Message.java does not change over the course of 
> runtime, and yet was being recalculated with every new message received. Make 
> this value static and only calculate it once to improve the performance of 
> messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6582) Performance Improvement: get max message size once

2019-04-01 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6582:
---

 Summary: Performance Improvement: get max message size once
 Key: GEODE-6582
 URL: https://issues.apache.org/jira/browse/GEODE-6582
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


The max message size in Message.java does not change over the course of 
runtime, and yet was being recalculated with every new message received. Make 
this value static and only calculate it once to improve the performance of 
messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6582) Performance Improvement: get max message size once

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6582:
---

Assignee: Helena Bales

> Performance Improvement: get max message size once
> --
>
> Key: GEODE-6582
> URL: https://issues.apache.org/jira/browse/GEODE-6582
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> The max message size in Message.java does not change over the course of 
> runtime, and yet was being recalculated with every new message received. Make 
> this value static and only calculate it once to improve the performance of 
> messages.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-5683) Remove unnecessarily gendered language from comments

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-5683.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Remove unnecessarily gendered language from comments
> 
>
> Key: GEODE-5683
> URL: https://issues.apache.org/jira/browse/GEODE-5683
> Project: Geode
>  Issue Type: Task
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.10.0, 1.8.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6580) Performance Improvement: in SocketCreator use concurrent hash map

2019-04-01 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6580:
---

 Summary: Performance Improvement: in SocketCreator use concurrent 
hash map
 Key: GEODE-6580
 URL: https://issues.apache.org/jira/browse/GEODE-6580
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


In SocketCreator, use ConcurrentHashMap instead of synchronizing on HashMap in 
order to reduce contention for locks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6580) Performance Improvement: in SocketCreator use concurrent hash map

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6580:
---

Assignee: Helena Bales

> Performance Improvement: in SocketCreator use concurrent hash map
> -
>
> Key: GEODE-6580
> URL: https://issues.apache.org/jira/browse/GEODE-6580
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> In SocketCreator, use ConcurrentHashMap instead of synchronizing on HashMap 
> in order to reduce contention for locks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6580) Performance Improvement: in SocketCreator use concurrent hash map

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6580:

Labels: performance-benchmark  (was: )

> Performance Improvement: in SocketCreator use concurrent hash map
> -
>
> Key: GEODE-6580
> URL: https://issues.apache.org/jira/browse/GEODE-6580
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
>
> In SocketCreator, use ConcurrentHashMap instead of synchronizing on HashMap 
> in order to reduce contention for locks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6515) Refactor connection pool to remove lock contention

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6515.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Refactor connection pool to remove lock contention
> --
>
> Key: GEODE-6515
> URL: https://issues.apache.org/jira/browse/GEODE-6515
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: benchmark
> Fix For: 1.10.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Solution should achieve near or even better throughput and latency as using 
> thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (GEODE-5683) Remove unnecessarily gendered language from comments

2019-04-01 Thread Helena Bales (JIRA)


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

Helena Bales reopened GEODE-5683:
-

> Remove unnecessarily gendered language from comments
> 
>
> Key: GEODE-5683
> URL: https://issues.apache.org/jira/browse/GEODE-5683
> Project: Geode
>  Issue Type: Task
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.8.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6577) Performance Improvement: init object in constructor

2019-03-29 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6577:
---

 Summary: Performance Improvement: init object in constructor
 Key: GEODE-6577
 URL: https://issues.apache.org/jira/browse/GEODE-6577
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


Initialize inexpensive object in the constructor for GemfireCacheImpl instead 
of in a hot code path, while holding a lock. This will result in a noticeable 
performance gain.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6577) Performance Improvement: init object in constructor

2019-03-29 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6577:

Labels: performance-benchmark  (was: )

> Performance Improvement: init object in constructor
> ---
>
> Key: GEODE-6577
> URL: https://issues.apache.org/jira/browse/GEODE-6577
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: performance-benchmark
>
> Initialize inexpensive object in the constructor for GemfireCacheImpl instead 
> of in a hot code path, while holding a lock. This will result in a noticeable 
> performance gain.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6577) Performance Improvement: init object in constructor

2019-03-29 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6577:
---

Assignee: Helena Bales

> Performance Improvement: init object in constructor
> ---
>
> Key: GEODE-6577
> URL: https://issues.apache.org/jira/browse/GEODE-6577
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Initialize inexpensive object in the constructor for GemfireCacheImpl instead 
> of in a hot code path, while holding a lock. This will result in a noticeable 
> performance gain.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6458) Support profiling benchmarks

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6458.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Support profiling benchmarks
> 
>
> Key: GEODE-6458
> URL: https://issues.apache.org/jira/browse/GEODE-6458
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Jacob S. Barrett
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add support for profiling benchmarks.
> * Upload profiler dependencies
> * Download profiler output
> * Pass profiler arguments to JVMs
> * Configure which JVMs get profiler arguments
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6510) update benchmark scripts for changes to key locations

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6510.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> update benchmark scripts for changes to key locations
> -
>
> Key: GEODE-6510
> URL: https://issues.apache.org/jira/browse/GEODE-6510
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Update the benchmark scripts for copying to cluster and running on cluster to 
> look for generated aws keys in the ~/.geode-benchmarks directory instead of 
> in ~/.ssh, to reflect recent changes to create cluster script.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6515) Refactor connection pool to remove lock contention

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6515:

Component/s: (was: benchmarks)
 client/server

> Refactor connection pool to remove lock contention
> --
>
> Key: GEODE-6515
> URL: https://issues.apache.org/jira/browse/GEODE-6515
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: benchmark
>
> Solution should achieve near or even better throughput and latency as using 
> thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6515) Refactor connection pool to remove lock contention

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6515:

Component/s: benchmarks

> Refactor connection pool to remove lock contention
> --
>
> Key: GEODE-6515
> URL: https://issues.apache.org/jira/browse/GEODE-6515
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Solution should achieve near or even better throughput and latency as using 
> thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6515) Refactor connection pool to remove lock contention

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6515:
---

Assignee: Helena Bales

> Refactor connection pool to remove lock contention
> --
>
> Key: GEODE-6515
> URL: https://issues.apache.org/jira/browse/GEODE-6515
> Project: Geode
>  Issue Type: Improvement
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Solution should achieve near or even better throughput and latency as using 
> thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (GEODE-6515) Refactor connection pool to remove lock contention

2019-03-12 Thread Helena Bales (JIRA)


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

Helena Bales updated GEODE-6515:

Labels: benchmark  (was: )

> Refactor connection pool to remove lock contention
> --
>
> Key: GEODE-6515
> URL: https://issues.apache.org/jira/browse/GEODE-6515
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>  Labels: benchmark
>
> Solution should achieve near or even better throughput and latency as using 
> thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6515) Refactor connection pool to remove lock contention

2019-03-12 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6515:
---

 Summary: Refactor connection pool to remove lock contention
 Key: GEODE-6515
 URL: https://issues.apache.org/jira/browse/GEODE-6515
 Project: Geode
  Issue Type: Improvement
Reporter: Helena Bales


Solution should achieve near or even better throughput and latency as using 
thread local connections.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6502) Update benchmark readme

2019-03-11 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6502.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Update benchmark readme
> ---
>
> Key: GEODE-6502
> URL: https://issues.apache.org/jira/browse/GEODE-6502
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Update benchmark readme to reflect all recent changes to AWS benchmark scripts



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6510) update benchmark scripts for changes to key locations

2019-03-11 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6510:
---

Assignee: Helena Bales

> update benchmark scripts for changes to key locations
> -
>
> Key: GEODE-6510
> URL: https://issues.apache.org/jira/browse/GEODE-6510
> Project: Geode
>  Issue Type: Bug
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Update the benchmark scripts for copying to cluster and running on cluster to 
> look for generated aws keys in the ~/.geode-benchmarks directory instead of 
> in ~/.ssh, to reflect recent changes to create cluster script.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6480) use long cli options in benchmark scripts

2019-03-11 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6480.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> use long cli options in benchmark scripts
> -
>
> Key: GEODE-6480
> URL: https://issues.apache.org/jira/browse/GEODE-6480
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> There are many cli options, and too many that start with the letter 'b', in 
> the benchmark scripts. This makes it difficult to remember all of the 
> single-letter cli options. Long (full-word) options would make it easier to 
> remember the option names for the benchmark scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6510) update benchmark scripts for changes to key locations

2019-03-11 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6510:
---

 Summary: update benchmark scripts for changes to key locations
 Key: GEODE-6510
 URL: https://issues.apache.org/jira/browse/GEODE-6510
 Project: Geode
  Issue Type: Bug
  Components: benchmarks
Reporter: Helena Bales


Update the benchmark scripts for copying to cluster and running on cluster to 
look for generated aws keys in the ~/.geode-benchmarks directory instead of in 
~/.ssh, to reflect recent changes to create cluster script.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6502) Update benchmark readme

2019-03-08 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6502:
---

 Summary: Update benchmark readme
 Key: GEODE-6502
 URL: https://issues.apache.org/jira/browse/GEODE-6502
 Project: Geode
  Issue Type: Improvement
  Components: benchmarks
Reporter: Helena Bales


Update benchmark readme to reflect all recent changes to AWS benchmark scripts



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6502) Update benchmark readme

2019-03-08 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6502:
---

Assignee: Helena Bales

> Update benchmark readme
> ---
>
> Key: GEODE-6502
> URL: https://issues.apache.org/jira/browse/GEODE-6502
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
>
> Update benchmark readme to reflect all recent changes to AWS benchmark scripts



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6479) Add username to keypair when creating AWS instances for benchmarks

2019-03-08 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6479.
-
Resolution: Fixed

> Add username to keypair when creating AWS instances for benchmarks
> --
>
> Key: GEODE-6479
> URL: https://issues.apache.org/jira/browse/GEODE-6479
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Add the current system username to AWS keypairs when creating instances for 
> running benchmark tests, to help reduce the number of instances that are left 
> running with no clear owners.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (GEODE-4267) PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId fails intermittently due to DistributedSystemDisconnectedException suspect string

2019-03-07 Thread Helena Bales (JIRA)


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

Helena Bales commented on GEODE-4267:
-

Failed again: 
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/473]

artifacts: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0023/test-results/distributedTest/1551919523/

> PersistentRecoveryOrderOldConfigDUnitTest.testCrashDuringPreparePersistentId 
> fails intermittently due to DistributedSystemDisconnectedException suspect 
> string
> --
>
> Key: GEODE-4267
> URL: https://issues.apache.org/jira/browse/GEODE-4267
> Project: Geode
>  Issue Type: Bug
>  Components: persistence, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Minor
>  Labels: Flaky
> Attachments: GEODE-4267-standard-output.txt, 
> lynn-findfailures-11-26-2018-15-25-48-logs.tgz
>
>
> {noformat}
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest
>  > testCrashDuringPreparePersistentId FAILED
> java.lang.RuntimeException: 
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: 
> This connection to a distributed system has been disconnected.
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1443
> [error 2017/12/16 00:50:26.778 UTC  
> tid=0x1b] 
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This 
> connection to a distributed system has been disconnected.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (GEODE-6479) Add username to keypair when creating AWS instances for benchmarks

2019-03-06 Thread Helena Bales (JIRA)


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

Helena Bales reopened GEODE-6479:
-

accidentally closed the wrong ticket

> Add username to keypair when creating AWS instances for benchmarks
> --
>
> Key: GEODE-6479
> URL: https://issues.apache.org/jira/browse/GEODE-6479
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add the current system username to AWS keypairs when creating instances for 
> running benchmark tests, to help reduce the number of instances that are left 
> running with no clear owners.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6474) CI failure: ConcurrencyRuleTest.repeatForDuration fails with ConditionTimeoutException

2019-03-06 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6474.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> CI failure: ConcurrencyRuleTest.repeatForDuration fails with 
> ConditionTimeoutException
> --
>
> Key: GEODE-6474
> URL: https://issues.apache.org/jira/browse/GEODE-6474
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>
> ConcurrencyRuleTest.repeatForDuration fails intermittently in CI:
> {noformat}
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest > 
> repeatForDuration(EXECUTE_IN_PARALLEL) [1] FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with alias 
> 'Execution respects given duration' didn't complete within 2000 milliseconds 
> because condition with lambda expression in 
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest was not fulfilled.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> org.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:860)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest.repeatForDuration(ConcurrencyRuleTest.java:398)
> {noformat}
> CI failure: 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/305|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/305]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0003/test-results/test/1551408641/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0003/test-artifacts/1551408641/windows-unittestfiles-OpenJDK11-1.10.0-SNAPSHOT.0003.tgz



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6422) CI Failure: ConcurrencyRuleTest. repeatUntilValue fails with TimeoutException

2019-03-06 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6422.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> CI Failure: ConcurrencyRuleTest. repeatUntilValue fails with TimeoutException
> -
>
> Key: GEODE-6422
> URL: https://issues.apache.org/jira/browse/GEODE-6422
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Benjamin P Ross
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Stack Trace: 
> {noformat}
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest > 
> repeatUntilValue(EXECUTE_IN_PARALLEL) [0] FAILED
> java.lang.RuntimeException: java.util.concurrent.TimeoutException
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRule$ProtectedErrorCollector.verify(ConcurrencyRule.java:489)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRule.executeInParallel(ConcurrencyRule.java:154)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest$Execution.lambda$static$1(ConcurrencyRuleTest.java:619)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest$Execution.execute(ConcurrencyRuleTest.java:629)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRuleTest.repeatUntilValue(ConcurrencyRuleTest.java:419)
> Caused by:
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:205)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRule.awaitFuture(ConcurrencyRule.java:227)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRule.awaitFutures(ConcurrencyRule.java:219)
> at 
> org.apache.geode.test.junit.rules.ConcurrencyRule.executeInParallel(ConcurrencyRule.java:153)
> ... 3 more
> {noformat}
> Artifacts can be downloaded: 
> gs://files-gemfire-dev/builds/gemfire-develop-main/1.9.0-build.0427/test-artifacts/1550270829/windows-unittestfiles-OpenJDK8-1.9.0-build.0427.tgz



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (GEODE-6479) Add username to keypair when creating AWS instances for benchmarks

2019-03-06 Thread Helena Bales (JIRA)


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

Helena Bales resolved GEODE-6479.
-
   Resolution: Fixed
Fix Version/s: 1.10.0

> Add username to keypair when creating AWS instances for benchmarks
> --
>
> Key: GEODE-6479
> URL: https://issues.apache.org/jira/browse/GEODE-6479
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Add the current system username to AWS keypairs when creating instances for 
> running benchmark tests, to help reduce the number of instances that are left 
> running with no clear owners.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (GEODE-6458) Support profiling benchmarks

2019-03-06 Thread Helena Bales (JIRA)


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

Helena Bales reassigned GEODE-6458:
---

Assignee: Helena Bales

> Support profiling benchmarks
> 
>
> Key: GEODE-6458
> URL: https://issues.apache.org/jira/browse/GEODE-6458
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Jacob S. Barrett
>Assignee: Helena Bales
>Priority: Major
>
> Add support for profiling benchmarks.
> * Upload profiler dependencies
> * Download profiler output
> * Pass profiler arguments to JVMs
> * Configure which JVMs get profiler arguments
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (GEODE-6480) use long cli options in benchmark scripts

2019-03-04 Thread Helena Bales (JIRA)
Helena Bales created GEODE-6480:
---

 Summary: use long cli options in benchmark scripts
 Key: GEODE-6480
 URL: https://issues.apache.org/jira/browse/GEODE-6480
 Project: Geode
  Issue Type: Improvement
  Components: benchmarks
Reporter: Helena Bales


There are many cli options, and too many that start with the letter 'b', in the 
benchmark scripts. This makes it difficult to remember all of the single-letter 
cli options. Long (full-word) options would make it easier to remember the 
option names for the benchmark scripts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


  1   2   3   >