Export Control for Geode

[Anthony Baker]

After reviewing [1], I think we need to record and report our use of
cryptographic libraries that fall under US export control.

This means:

1) Updating the eccnmatrix.xml [2] in svn and publishing the change [3].
2) Sending an email [4].
3) Updating README.md [5].

Mark, #1 and #2 need to be done by the PMC Chair.  Can you review this
and let me know what you think?  I can tackle #3 after.

Thanks,
Anthony

[1] http://www.apache.org/dev/crypto.html
[2] https://gist.github.com/metatype/96da9d928f20d5ae638cc16dd4ee9a85
[3] https://cms.apache.org/www/publish
[4] https://gist.github.com/metatype/24b4462af6319cbf568b63ad3a56464e
[5] 
https://gist.githubusercontent.com/metatype/b50b49a4c2a7a99793029b3ea0cde8c3/raw/40aca011a65c12d6fbec73fce60f57f43323d36f/README.md

[jira] [Updated] (GEODE-2588) OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for the same amount of data and same resources

[Christian Tzolov (JIRA)]

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

Christian Tzolov updated GEODE-2588:

Attachment: oql_with_order_by_hot_methods.png

>From the profiler it is clear that the *OrderByComparator* and particularly 
>the *OrderByComparator#evaluateSortCriteria* method are taking most of the CPU 
>resources

> OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for 
> the same amount of data and same resources
> -
>
> Key: GEODE-2588
> URL: https://issues.apache.org/jira/browse/GEODE-2588
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Christian Tzolov
> Attachments: flight_recording_OQL_ORDER_BY.jfr, 
> gemfire_OQL_ORDER_BY.log, 
> gemfire-oql-orderby-vs-on-client-sort-test-cases.zip, 
> myStats_OQL_ORDER_BY.gfs, oql_with_order_by_hot_methods.png
>
>
> For Partition Region with 1 500 000 entries running on a single Geode member.
> The OQL query *SELECT DISTINCT a, b FROM /region ORDER BY b* takes *13x* 
> times (*1300%*) more time compared to OQL *SELECT a, b FROM /region* +  
> manual Java sort of the result for the same dataset.
> Setup: Geode 1.0.0 with Partition region with 1 500 000 objects, 4GB memory
> 1. OQL with DISTINCT/ORDER BY
> {code}SELECT DISTINCT e.key,e.day FROM /partitionRegion e ORDER BY e.day{code}
> OQL execution time: 64899 ms = *~65 sec*
> 2. OQL with manual sort
> {code}SELECT e.key,e.day FROM /partitionRegion e{code}
> and then
> {code}
> //OQL all -> 3058 ms
> SelectResults result = (SelectResults) query.execute(bindings);
> //Client-side sort -> 1830 ms
> List result2 = (List) result.asList().parallelStream().sorted((o1, o2) 
> -> {
> Struct st1 = (Struct) o1;
> Struct st2 = (Struct) o2;
> return ((Date) st1.get("day")).compareTo((Date) st2.get("day"));
> }).collect(toList());
> {code}
> OQL execution time: 3058 ms,
> Client-side sort time: 1830 ms
> Total time: 4888 ms = *~5 sec*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2588) OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for the same amount of data and same resources

[Christian Tzolov (JIRA)]

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

Christian Tzolov updated GEODE-2588:

Attachment: myStats_OQL_ORDER_BY.gfs
gemfire_OQL_ORDER_BY.log
flight_recording_OQL_ORDER_BY.jfr

Logs, statistics and JMC profile for running the test project with OQL ORDER BY

> OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for 
> the same amount of data and same resources
> -
>
> Key: GEODE-2588
> URL: https://issues.apache.org/jira/browse/GEODE-2588
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Christian Tzolov
> Attachments: flight_recording_OQL_ORDER_BY.jfr, 
> gemfire_OQL_ORDER_BY.log, 
> gemfire-oql-orderby-vs-on-client-sort-test-cases.zip, myStats_OQL_ORDER_BY.gfs
>
>
> For Partition Region with 1 500 000 entries running on a single Geode member.
> The OQL query *SELECT DISTINCT a, b FROM /region ORDER BY b* takes *13x* 
> times (*1300%*) more time compared to OQL *SELECT a, b FROM /region* +  
> manual Java sort of the result for the same dataset.
> Setup: Geode 1.0.0 with Partition region with 1 500 000 objects, 4GB memory
> 1. OQL with DISTINCT/ORDER BY
> {code}SELECT DISTINCT e.key,e.day FROM /partitionRegion e ORDER BY e.day{code}
> OQL execution time: 64899 ms = *~65 sec*
> 2. OQL with manual sort
> {code}SELECT e.key,e.day FROM /partitionRegion e{code}
> and then
> {code}
> //OQL all -> 3058 ms
> SelectResults result = (SelectResults) query.execute(bindings);
> //Client-side sort -> 1830 ms
> List result2 = (List) result.asList().parallelStream().sorted((o1, o2) 
> -> {
> Struct st1 = (Struct) o1;
> Struct st2 = (Struct) o2;
> return ((Date) st1.get("day")).compareTo((Date) st2.get("day"));
> }).collect(toList());
> {code}
> OQL execution time: 3058 ms,
> Client-side sort time: 1830 ms
> Total time: 4888 ms = *~5 sec*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2588) OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for the same amount of data and same resources

[Christian Tzolov (JIRA)]

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

Christian Tzolov updated GEODE-2588:

Attachment: gemfire-oql-orderby-vs-on-client-sort-test-cases.zip

Demo project to illustrate the issue. 
1. Run with ORDER BY:
{code}
java -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC -Xmx4G -Dgemfire.jmx-manager-port=1199 
-Dgemfire.jmx-manager=true -Dgemfire.jmx-manager-start=true  
-Dgemfire.locators=localhost[10334] -Dgemfire.start-locator=localhost[10334] 
-Dgemfire.enable-cluster-configuration=false 
-Dgemfire.statistic-sampling-enabled=true 
-Dgemfire.statistic-archive-file=myStats.gfs 
-Dgemfire.enable-time-statistics=true -Dgemfire.jmx-manager-update-rate=2000 
-jar ./target/gemfire-tests-0.0.1-SNAPSHOT.jar
{code}
2. Run with on client sort
{code}
java -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC -Xmx4G -Dgemfire.jmx-manager-port=1199 
-Dgemfire.jmx-manager=true -Dgemfire.jmx-manager-start=true  
-Dgemfire.locators=localhost[10334] -Dgemfire.start-locator=localhost[10334] 
-Dgemfire.enable-cluster-configuration=false 
-Dgemfire.statistic-sampling-enabled=true 
-Dgemfire.statistic-archive-file=myStats.gfs 
-Dgemfire.enable-time-statistics=true -Dgemfire.jmx-manager-update-rate=2000 
-jar ./target/gemfire-tests-0.0.1-SNAPSHOT.jar on-client-sort
{code}

> OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for 
> the same amount of data and same resources
> -
>
> Key: GEODE-2588
> URL: https://issues.apache.org/jira/browse/GEODE-2588
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Christian Tzolov
> Attachments: gemfire-oql-orderby-vs-on-client-sort-test-cases.zip
>
>
> For Partition Region with 1 500 000 entries running on a single Geode member.
> The OQL query *SELECT DISTINCT a, b FROM /region ORDER BY b* takes *13x* 
> times (*1300%*) more time compared to OQL *SELECT a, b FROM /region* +  
> manual Java sort of the result for the same dataset.
> Setup: Geode 1.0.0 with Partition region with 1 500 000 objects, 4GB memory
> 1. OQL with DISTINCT/ORDER BY
> {code}SELECT DISTINCT e.key,e.day FROM /partitionRegion e ORDER BY e.day{code}
> OQL execution time: 64899 ms = *~65 sec*
> 2. OQL with manual sort
> {code}SELECT e.key,e.day FROM /partitionRegion e{code}
> and then
> {code}
> //OQL all -> 3058 ms
> SelectResults result = (SelectResults) query.execute(bindings);
> //Client-side sort -> 1830 ms
> List result2 = (List) result.asList().parallelStream().sorted((o1, o2) 
> -> {
> Struct st1 = (Struct) o1;
> Struct st2 = (Struct) o2;
> return ((Date) st1.get("day")).compareTo((Date) st2.get("day"));
> }).collect(toList());
> {code}
> OQL execution time: 3058 ms,
> Client-side sort time: 1830 ms
> Total time: 4888 ms = *~5 sec*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2588) OQL's ORDER BY takes 13x (1300%) more time compared to plain java sort for the same amount of data and same resources

[Christian Tzolov (JIRA)]

Christian Tzolov created GEODE-2588:
---

 Summary: OQL's ORDER BY takes 13x (1300%) more time compared to 
plain java sort for the same amount of data and same resources
 Key: GEODE-2588
 URL: https://issues.apache.org/jira/browse/GEODE-2588
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Christian Tzolov


For Partition Region with 1 500 000 entries running on a single Geode member.
The OQL query *SELECT DISTINCT a, b FROM /region ORDER BY b* takes *13x* times 
(*1300%*) more time compared to OQL *SELECT a, b FROM /region* +  manual Java 
sort of the result for the same dataset.

Setup: Geode 1.0.0 with Partition region with 1 500 000 objects, 4GB memory

1. OQL with DISTINCT/ORDER BY
{code}SELECT DISTINCT e.key,e.day FROM /partitionRegion e ORDER BY e.day{code}
OQL execution time: 64899 ms = *~65 sec*

2. OQL with manual sort
{code}SELECT e.key,e.day FROM /partitionRegion e{code}
and then
{code}
//OQL all -> 3058 ms
SelectResults result = (SelectResults) query.execute(bindings);

//Client-side sort -> 1830 ms
List result2 = (List) result.asList().parallelStream().sorted((o1, o2) -> 
{
Struct st1 = (Struct) o1;
Struct st2 = (Struct) o2;
return ((Date) st1.get("day")).compareTo((Date) st2.get("day"));
}).collect(toList());
{code}
OQL execution time: 3058 ms,
Client-side sort time: 1830 ms
Total time: 4888 ms = *~5 sec*



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2587) Refactor OrderByComparator's compare method

[nabarun (JIRA)]

nabarun created GEODE-2587:
--

 Summary: Refactor OrderByComparator's compare method
 Key: GEODE-2587
 URL: https://issues.apache.org/jira/browse/GEODE-2587
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: nabarun


OrderByComparator's compare method creates a lot of objects / arrays with the 
intention of comparing two objects.
But allocation of memory for these objects results in GC to kick in.
The additional time consumed in GC results in increased execution time for 
queries with ORDER BY clause.

This method must be refactored to require less memory allocations in order to 
compare and thus speed up ORDER BY clause.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2586) ServerOperationException Message: Not providing remote server id

[Hitesh Khamesra (JIRA)]

Hitesh Khamesra created GEODE-2586:
--

 Summary: ServerOperationException Message: Not providing remote 
server id
 Key: GEODE-2586
 URL: https://issues.apache.org/jira/browse/GEODE-2586
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Hitesh Khamesra


It seems following code need to get remote server id in 
ServerOperationException class

 private static String getServerMessage(String msg) {
// To fix bug 44679 add a description of the member the server is on.
// Do this without changing how this class gets serialized so that old
// clients will still work.
InternalDistributedSystem ids = InternalDistributedSystem.getAnyInstance();
if (ids != null) {
  if (msg != null) {
return "remote server on " + ids.getMemberId() + ": " + msg;
  } else {
return "remote server on " + ids.getMemberId();
  }
} else {
  if (msg != null) {
return "remote server on unknown location: " + msg;
  } else {
return "remote server on unknown location";
  }
}
  }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Also Requesting more JIRA permission

[Diane Rose Hardman]

dhardman

On Thu, Mar 2, 2017 at 9:30 AM, Dan Smith  wrote:

> Hi Diane,
>
> What's your JIRA userid?
>
> -Dan
>
> On Wed, Mar 1, 2017 at 5:17 PM, Diane Rose Hardman 
> wrote:
>
> > Similar to Addison's request earlier, as a PM I too would like pmerission
> > to edit Jira tickets.
> > Addison and I have discussed ways to better organize our process of
> pulling
> > Jira tickets into our backlogs and this would really help.
> >
> > Thanks,
> > Diane
> >
>

[jira] [Updated] (GEODE-2584) Client can put a register object on the server

[Addison (JIRA)]

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

Addison updated GEODE-2584:
---
Description: Client should be able to send a put method, a region, a key, 
and a registered object to the server so that it can be storied there.  (was: 
Client should be able to send a put method, and key, and a registered object to 
the server so that it can be storied there.)

> Client can put a register object on the server
> --
>
> Key: GEODE-2584
> URL: https://issues.apache.org/jira/browse/GEODE-2584
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> Client should be able to send a put method, a region, a key, and a registered 
> object to the server so that it can be storied there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2585) Client can get an object from the server

[Addison (JIRA)]

Addison created GEODE-2585:
--

 Summary: Client can get an object from the server
 Key: GEODE-2585
 URL: https://issues.apache.org/jira/browse/GEODE-2585
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Addison


The client should be able to send a message to the server with a region and a 
key and get the serialized object back.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2584) Client can put a register object on the server

[Addison (JIRA)]

Addison created GEODE-2584:
--

 Summary: Client can put a register object on the server
 Key: GEODE-2584
 URL: https://issues.apache.org/jira/browse/GEODE-2584
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Addison


Client should be able to send a put method, and key, and a registered object to 
the server so that it can be storied there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2583) Client can register a type with the server

[Addison (JIRA)]

Addison created GEODE-2583:
--

 Summary: Client can register a type with the server
 Key: GEODE-2583
 URL: https://issues.apache.org/jira/browse/GEODE-2583
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Addison


The client should be able to send a message to register a new type with the 
server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/
---

(Updated March 3, 2017, 12:03 a.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Repository: geode


Description (updated)
---

GEODE-2267: Enhance server/locator startup rules to include workingDir

* This batch is mostly test code change, I am enhancing the ServerStartupRules 
and LocatorStartupRules to have a notion of workingDir itself.
* There are only 2 product code change: one is the assembly's build.gradle to 
correctly set the gemfire.home/geode.home, another one is to use an absolute 
path to check for File's exsistance. Without that, the tests always fail in CI 
pipeline.

New round of refactoring on top of the old one:

* be able to return the rule itself so that we can start the server/locator at 
rule declaration time.
* rearrange the class structure
* do not delete the workingDir if the rule is created with a workingDir (then 
it's up for the caller to delete it)

I will need to get the batch in after our export log merge though.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 75a3c2c0996972cab26dc6dad79f675ddfb8f6b3 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
 933f7b2ad73b76def7fb1029d4f424f77d1a4211 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 fa98ce69559ed5bbdd1eb320734090c3de007106 
  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 83a367eb88aec85984691e651e5de0f8b479c7cb 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
 c6248e052ea8d8579c4f5b2b4de9ec74dca30e72 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 4ac98864eed9330fce519e4a7054cb8ab6201cae 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 15e6ea6ec15759800f07e05e8a2bbc6b2d586754 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 e134c42ed88ee7f61e76dcb4503b7ffc13bd2276 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 72daf0d07feb25a23be84b4a2aae1c1a7668e64c 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 c0d22bfc697e886cbdb074d9ad5b3241dab93e03 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
 4d67fb0fe4d54299b4b2a523aee0d9126a1e3836 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
 30e1df85da4b6040594ef81bbf9ff5b0dc6f2c31 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
 646819559f608e8262b90e6774f62b2b15b56a82 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
 d1750c3a5efd636c0f9f47fabe670265bf46f072 
  
geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
 b6d108016f44e3bbafd6c3975d9827a7ac479706 
  
geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
 5d713f6bf91fcd74e77ba6ed8c1040c605a954ce 
  
geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
 12c2da3d000669ea3b28d52bd80d96a17adfa15e 
  
geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
 092e82b82a8438a3be3394fd997ec727cda5b782 
  
geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
 f5cfff613300b758b20f3c2acfb875cfa4804d79 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 4729be3f4d9b51168422784a57ac1ec76e018e83 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
b1004b9cee8c2f2aae96664966aa0e6c7a565fdc 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 39c13d000db80bef37563729bc17ae4bcb566153 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
 84c660cfe0ab9b7c6ba0bfc08b034ccaf17697f0 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
5f46da21f380a67a8e7f4855da1dfbb3118057ba 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 PRE-CREATION 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
PRE-CREATION 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
83093c4c8963b64020d7ed8f573e904fccd32e2e 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.ja

[jira] [Created] (GEODE-2582) Client can connect to a Geode Server

[Addison (JIRA)]

Addison created GEODE-2582:
--

 Summary: Client can connect to a Geode Server
 Key: GEODE-2582
 URL: https://issues.apache.org/jira/browse/GEODE-2582
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Addison


A client should be able to send a connection request so that it can start 
interacting with server and the developer knows things are working.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/
---

(Updated March 3, 2017, 12:01 a.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Changes
---

precheckin running


Repository: geode


Description
---

GEODE-2267: Enhance server/locator startup rules to include workingDir

* This batch is mostly test code change, I am enhancing the ServerStartupRules 
and LocatorStartupRules to have a notion of workingDir itself.
* There are only 2 product code change: one is the assembly's build.gradle to 
correctly set the gemfire.home/geode.home, another one is to use an absolute 
path to check for File's exsistance. Without that, the tests always fail in CI 
pipeline.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
 75a3c2c0996972cab26dc6dad79f675ddfb8f6b3 
  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
 933f7b2ad73b76def7fb1029d4f424f77d1a4211 
  
geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
 fa98ce69559ed5bbdd1eb320734090c3de007106 
  
geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
 83a367eb88aec85984691e651e5de0f8b479c7cb 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
 c6248e052ea8d8579c4f5b2b4de9ec74dca30e72 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 4ac98864eed9330fce519e4a7054cb8ab6201cae 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 15e6ea6ec15759800f07e05e8a2bbc6b2d586754 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDistributionDUnitTest.java
 e134c42ed88ee7f61e76dcb4503b7ffc13bd2276 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 72daf0d07feb25a23be84b4a2aae1c1a7668e64c 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 c0d22bfc697e886cbdb074d9ad5b3241dab93e03 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigWithSecurityDUnitTest.java
 4d67fb0fe4d54299b4b2a523aee0d9126a1e3836 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
 30e1df85da4b6040594ef81bbf9ff5b0dc6f2c31 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
 646819559f608e8262b90e6774f62b2b15b56a82 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
 d1750c3a5efd636c0f9f47fabe670265bf46f072 
  
geode-core/src/test/java/org/apache/geode/security/AbstractSecureServerDUnitTest.java
 b6d108016f44e3bbafd6c3975d9827a7ac479706 
  
geode-core/src/test/java/org/apache/geode/security/ClusterConfigWithoutSecurityDUnitTest.java
 5d713f6bf91fcd74e77ba6ed8c1040c605a954ce 
  
geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
 12c2da3d000669ea3b28d52bd80d96a17adfa15e 
  
geode-core/src/test/java/org/apache/geode/security/SecurityWithoutClusterConfigDUnitTest.java
 092e82b82a8438a3be3394fd997ec727cda5b782 
  
geode-core/src/test/java/org/apache/geode/security/StartServerAuthorizationTest.java
 f5cfff613300b758b20f3c2acfb875cfa4804d79 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 4729be3f4d9b51168422784a57ac1ec76e018e83 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
b1004b9cee8c2f2aae96664966aa0e6c7a565fdc 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 39c13d000db80bef37563729bc17ae4bcb566153 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
 84c660cfe0ab9b7c6ba0bfc08b034ccaf17697f0 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
5f46da21f380a67a8e7f4855da1dfbb3118057ba 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
 PRE-CREATION 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
PRE-CREATION 
  geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
83093c4c8963b64020d7ed8f573e904fccd32e2e 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 df3757950c2fd28521958416d763cb1e41ae6456 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java
 1a344db6be8003fe21bb505362e77a1864e88264 


Diff: https://reviews.apache.org/r/57242/diff/2/

Changes: https://reviews.apache.org/r/57242/diff/1-2/


Testing
--

[jira] [Created] (GEODE-2581) New Client/Server Protocol Design Proposal

[Addison (JIRA)]

Addison created GEODE-2581:
--

 Summary: New Client/Server Protocol Design Proposal
 Key: GEODE-2581
 URL: https://issues.apache.org/jira/browse/GEODE-2581
 Project: Geode
  Issue Type: Sub-task
  Components: messaging
Reporter: Addison


The goal here is the create a high-level design document that outlines the 
foundational design choices of the new protocol.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2580) New Client/Server Protocol to make the development of clients easier

[Addison (JIRA)]

Addison created GEODE-2580:
--

 Summary: New Client/Server Protocol to make the development of 
clients easier
 Key: GEODE-2580
 URL: https://issues.apache.org/jira/browse/GEODE-2580
 Project: Geode
  Issue Type: Wish
  Components: messaging
Reporter: Addison


Today, writing a client in a new language (e.g. Go, Ruby, etc) is difficult be 
the client/server protocol is now well documented and optimized for super-low 
latency over maintainability.  The goal of this this epic is to write a new 
client/server protocol that is well documented that will be the foundation for 
future Geode client.

This epic is broken down in the sub-tasks below.

Please vote on this wish if you think it is a worthwhile endeavor.

Note: no design choices are being made just yet. The first sub-task in this 
epic is to make a former proposal to the developer list to discuss foundational 
design choices.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r104059948
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/executor/hash/HashInterpreter.java
 ---
@@ -0,0 +1,126 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.redis.internal.executor.hash;
+
+import java.util.Map;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.redis.GeodeRedisServer;
+import org.apache.geode.redis.internal.ByteArrayWrapper;
+import org.apache.geode.redis.internal.Coder;
+import org.apache.geode.redis.internal.ExecutionHandlerContext;
+import org.apache.geode.redis.internal.RedisDataType;
+
+/**
+ * Utility class for interpreting and processing Redis Hash data structure
+ * 
+ *
+ */
+public class HashInterpreter {
+
+  /**
+   * 
+   * The region:key separator.
+   * 
+   *  REGION_KEY_SEPERATOR = ":"
+   * 
+   * See Hash section of https://redis.io/topics/data-types";>https://redis.io/topics/data-types#Hashes
+   * 
+   */
+  public static final String REGION_KEY_SEPERATOR = ":";
+
+  /**
+   * The default hash region name REGION_HASH_REGION = 
Coder.stringToByteArrayWrapper("ReDiS_HASH")
+   */
+  public static final ByteArrayWrapper REGION_HASH_REGION =
+  Coder.stringToByteArrayWrapper(GeodeRedisServer.HASH_REGION);
+
+  /**
+   * Return the region presenting the hash
+   * 
+   * @param key the raw Redis command key that may contain the region:key 
formation
+   * @param context the exception handler context
+   * @return the region were the command's data will be processed
+   */
+  @SuppressWarnings("unchecked")
+  public static Region> getRegion(
--- End diff --

I think the abstraction would be cleaner if  the HashInterpreter 
implemented `setHash` and `getHash` (and `setHashKey` and `getHashKey`) 
methods, and callers didn't have to think about regions at all. It would also 
make it clearer where the single point of concern is for where and how hashes 
get stored.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-1793:
-

In another run with modified logging I can see that the SSL locator did not see 
an SSLHandshakeException as expected but merely an IOException

[vm2] [info 2017/03/02 15:40:00.701 PST  
tid=0x13] Peer locator could not recover membership view from 
trout.gemstone.com/10.118.32.92:38254: Connection reset

So this appears to be an inconsistency in SSL implementations used by the JVM.

> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> ---
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined 
> what the problem is, but it will run perfectly by itself everytime, but once 
> run inside of the TestClass it fails



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-1793:
-

I managed to get this test to fail & see that the second locator, in vm_2, was 
supposed to shut down but instead it created its own cluster:

{noformat}
[vm2] [info 2017/03/02 15:19:56.969 PST  
tid=0x13] Starting membership services

[vm2] [info 2017/03/02 15:19:56.979 PST  
tid=0x13] JGroups channel created (took 9ms)

[vm2] [info 2017/03/02 15:19:56.980 PST  
tid=0x13] GemFire P2P Listener started on /10.118.32.92:39824

[vm2] [info 2017/03/02 15:19:56.980 PST  tid=0x21c] Started failure detection server thread on /10.118.32.92:59150.

[vm2] [info 2017/03/02 15:19:56.980 PST  
tid=0x13] Peer locator is connecting to local membership services with ID 
trout(2830:locator):32771

[vm2] [info 2017/03/02 15:19:57.164 PST  
tid=0x13] This member is becoming the membership coordinator with address 
trout(2830:locator):32771
{noformat}

It was correctly configured with two locator addresses and its SSL 
configuration appeared to be okay.  The other locator, in vm_1, correctly had 
SSL disabled.  The SSL locator was unable to recover from the non-SSL locator:

{noformat}
[vm2] [info 2017/03/02 15:19:56.961 PST  
tid=0x13] GemFire peer location service starting.  Other locators: 
trout.gemstone.com[46843]  Locators preferred as coordinators: false  Network 
partition detection enabled: false  View persistence file: locator0view.dat

[vm2] [info 2017/03/02 15:19:56.961 PST  
tid=0x13] Peer locator attempting to recover from 
trout.gemstone.com/10.118.32.92:46843

[vm2] [info 2017/03/02 15:19:56.963 PST  
tid=0x13] Peer locator was unable to recover state from this locator

[vm2] [info 2017/03/02 15:19:56.963 PST  
tid=0x13] recovery file not found: 
/export/trout1/users/bschuchardt/devel/gfdev/open/geode-core/build/distributedTest/dunit/vm2/locator0view.dat

[vm2] [info 2017/03/02 15:19:56.963 PST  
tid=0x13] Starting distributed system
{noformat}

So this appears to be a problem with Geode, not the test.  It is the Geode 
functionality that is "flaky", working most of the time but not 100%.

> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> ---
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined 
> what the problem is, but it will run perfectly by itself everytime, but once 
> run inside of the TestClass it fails



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r104041093
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/executor/hash/HDelExecutor.java
 ---
@@ -40,25 +38,25 @@ public void executeCommand(Command command, 
ExecutionHandlerContext context) {
 int numDeleted = 0;
 
 ByteArrayWrapper key = command.getKey();
+Map map = getMap(context, key);
 
-checkDataType(key, RedisDataType.REDIS_HASH, context);
-Region keyRegion = 
getRegion(context, key);
-
-if (keyRegion == null) {
+if (map == null || map.isEmpty()) {
   
command.setResponse(Coder.getIntegerResponse(context.getByteBufAllocator(), 
numDeleted));
   return;
 }
 
-
 for (int i = START_FIELDS_INDEX; i < commandElems.size(); i++) {
   ByteArrayWrapper field = new ByteArrayWrapper(commandElems.get(i));
-  Object oldValue = keyRegion.remove(field);
+  Object oldValue = map.remove(field);
   if (oldValue != null)
 numDeleted++;
 }
-if (keyRegion.isEmpty()) {
-  context.getRegionProvider().removeKey(key, RedisDataType.REDIS_HASH);
-}
+// save map
+saveMap(map, context, key);
+
+// if (map.isEmpty()) {
--- End diff --

Would prefer to remove code rather than comment it out.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r104041266
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java ---
@@ -442,9 +502,10 @@ protected void checkDataType(ByteArrayWrapper key, 
RedisDataType type) {
   return;
 if (currentType == RedisDataType.REDIS_PROTECTED)
   throw new RedisDataTypeMismatchException("The key name \"" + key + 
"\" is protected");
-if (currentType != type)
-  throw new RedisDataTypeMismatchException(
-  "The key name \"" + key + "\" is already used by a " + 
currentType.toString());
+/*
--- End diff --

Would prefer to remove code rather than comment it out.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r104031973
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java ---
@@ -442,9 +502,10 @@ protected void checkDataType(ByteArrayWrapper key, 
RedisDataType type) {
   return;
 if (currentType == RedisDataType.REDIS_PROTECTED)
   throw new RedisDataTypeMismatchException("The key name \"" + key + 
"\" is protected");
-if (currentType != type)
--- End diff --

Why has this been removed?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (GEODE-2579) ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Jason Huynh (JIRA)]

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

Jason Huynh updated GEODE-2579:
---
Affects Version/s: 1.0.0-incubating

> ClassCastException cannot cast CompiledIn to CompiledJunction when querying 
> with a junction containing an in clause
> ---
>
> Key: GEODE-2579
> URL: https://issues.apache.org/jira/browse/GEODE-2579
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> A query that causes a junction to form with a compiled in clause may throw 
> the following exception: 
> java.lang.ClassCastException: 
> org.apache.geode.cache.query.internal.CompiledIn cannot be cast to 
> org.apache.geode.cache.query.internal.CompiledJunction
>   at 
> org.apache.geode.cache.query.internal.AbstractGroupOrRangeJunction.(AbstractGroupOrRangeJunction.java:78)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.(GroupJunction.java:55)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.recreateFromOld(GroupJunction.java:61)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.evaluateAndJunction(CompositeGroupJunction.java:348)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.filterEvaluate(CompositeGroupJunction.java:93)
>   at 
> org.apache.geode.cache.query.internal.CompiledJunction.filterEvaluate(CompiledJunction.java:187)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:579)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:391)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:323)
>   at 
> org.apache.geode.cache.query.QueryJUnitTest.creatingACompiledJunctionWithACompiledInClauseDoesNotThrowException(QueryJUnitTest.java:334)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> A sample query would be :
> select 
> regionB.userId,regionA.professionCode,regionB.postCode,regionB.userName from 
> /regionA regionA,/regionB regionB w

[jira] [Created] (GEODE-2579) ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2579:
--

 Summary: ClassCastException cannot cast CompiledIn to 
CompiledJunction when querying with a junction containing an in clause
 Key: GEODE-2579
 URL: https://issues.apache.org/jira/browse/GEODE-2579
 Project: Geode
  Issue Type: Bug
  Components: querying
Reporter: Jason Huynh


A query that causes a junction to form with a compiled in clause may throw the 
following exception: 
java.lang.ClassCastException: org.apache.geode.cache.query.internal.CompiledIn 
cannot be cast to org.apache.geode.cache.query.internal.CompiledJunction

at 
org.apache.geode.cache.query.internal.AbstractGroupOrRangeJunction.(AbstractGroupOrRangeJunction.java:78)
at 
org.apache.geode.cache.query.internal.GroupJunction.(GroupJunction.java:55)
at 
org.apache.geode.cache.query.internal.GroupJunction.recreateFromOld(GroupJunction.java:61)
at 
org.apache.geode.cache.query.internal.CompositeGroupJunction.evaluateAndJunction(CompositeGroupJunction.java:348)
at 
org.apache.geode.cache.query.internal.CompositeGroupJunction.filterEvaluate(CompositeGroupJunction.java:93)
at 
org.apache.geode.cache.query.internal.CompiledJunction.filterEvaluate(CompiledJunction.java:187)
at 
org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
at 
org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
at 
org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:579)
at 
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:391)
at 
org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:323)
at 
org.apache.geode.cache.query.QueryJUnitTest.creatingACompiledJunctionWithACompiledInClauseDoesNotThrowException(QueryJUnitTest.java:334)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)


A sample query would be :
select regionB.userId,regionA.professionCode,regionB.postCode,regionB.userName 
from /regionA regionA,/regionB regionB where regionA.userId = regionB.userId 
and regionA.professionCode in Set('1','2','3') and regionB.postCode = '1' and 
regionB.userId='1'"



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2579) ClassCastException cannot cast CompiledIn to CompiledJunction when querying with a junction containing an in clause

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2579:
--

Assignee: Jason Huynh

> ClassCastException cannot cast CompiledIn to CompiledJunction when querying 
> with a junction containing an in clause
> ---
>
> Key: GEODE-2579
> URL: https://issues.apache.org/jira/browse/GEODE-2579
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Affects Versions: 1.0.0-incubating
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> A query that causes a junction to form with a compiled in clause may throw 
> the following exception: 
> java.lang.ClassCastException: 
> org.apache.geode.cache.query.internal.CompiledIn cannot be cast to 
> org.apache.geode.cache.query.internal.CompiledJunction
>   at 
> org.apache.geode.cache.query.internal.AbstractGroupOrRangeJunction.(AbstractGroupOrRangeJunction.java:78)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.(GroupJunction.java:55)
>   at 
> org.apache.geode.cache.query.internal.GroupJunction.recreateFromOld(GroupJunction.java:61)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.evaluateAndJunction(CompositeGroupJunction.java:348)
>   at 
> org.apache.geode.cache.query.internal.CompositeGroupJunction.filterEvaluate(CompositeGroupJunction.java:93)
>   at 
> org.apache.geode.cache.query.internal.CompiledJunction.filterEvaluate(CompiledJunction.java:187)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:545)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:57)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:579)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:391)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:323)
>   at 
> org.apache.geode.cache.query.QueryJUnitTest.creatingACompiledJunctionWithACompiledInClauseDoesNotThrowException(QueryJUnitTest.java:334)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:483)
>   at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> A sample query would be :
> select 
> regionB.userId,regionA.professionCode,regionB.postCode,regionB.userName from 
> /regionA regionA,/regionB regionB where re

[jira] [Commented] (GEODE-2578) Query string limited to 64 KiB

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PivotalSarge opened a pull request:

https://github.com/apache/geode-native/pull/44

GEODE-2578: Remove 64 KiB limit on query strings.

- Remove artificial cap of 65535 for query string
  length by using 32 bits for the length of query
  strings in DataOutput::writeFullUTF().
- Rename parameter to TcrMessage::writeStringPart()
  whose name is misleading due to copy-and-paste.
- Add three unit tests for query-related messages:
  * testConstructorEXECUTECQ_MSG_TYPE
  * testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE
  * testConstructorEXECUTECQ_WITH_IR_MSG_TYPE

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PivotalSarge/geode-native feature/GEODE-2578

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-native/pull/44.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #44


commit 542c6349c7194558f463732a96a0e32a216a17a3
Author: Sarge 
Date:   2017-03-02T22:45:37Z

GEODE-2578: Remove 64 KiB limit on query strings.

- Remove artificial cap of 65535 for query string
  length by using 32 bits for the length of query
  strings in DataOutput::writeFullUTF().
- Rename parameter to TcrMessage::writeStringPart()
  whose name is misleading due to copy-and-paste.
- Add three unit tests for query-related messages:
  * testConstructorEXECUTECQ_MSG_TYPE
  * testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE
  * testConstructorEXECUTECQ_WITH_IR_MSG_TYPE




> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode-native pull request #44: GEODE-2578: Remove 64 KiB limit on query stri...

[PivotalSarge]

GitHub user PivotalSarge opened a pull request:

https://github.com/apache/geode-native/pull/44

GEODE-2578: Remove 64 KiB limit on query strings.

- Remove artificial cap of 65535 for query string
  length by using 32 bits for the length of query
  strings in DataOutput::writeFullUTF().
- Rename parameter to TcrMessage::writeStringPart()
  whose name is misleading due to copy-and-paste.
- Add three unit tests for query-related messages:
  * testConstructorEXECUTECQ_MSG_TYPE
  * testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE
  * testConstructorEXECUTECQ_WITH_IR_MSG_TYPE

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PivotalSarge/geode-native feature/GEODE-2578

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-native/pull/44.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #44


commit 542c6349c7194558f463732a96a0e32a216a17a3
Author: Sarge 
Date:   2017-03-02T22:45:37Z

GEODE-2578: Remove 64 KiB limit on query strings.

- Remove artificial cap of 65535 for query string
  length by using 32 bits for the length of query
  strings in DataOutput::writeFullUTF().
- Rename parameter to TcrMessage::writeStringPart()
  whose name is misleading due to copy-and-paste.
- Add three unit tests for query-related messages:
  * testConstructorEXECUTECQ_MSG_TYPE
  * testConstructorWithGinormousQueryEXECUTECQ_MSG_TYPE
  * testConstructorEXECUTECQ_WITH_IR_MSG_TYPE




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] geode pull request #410: Overhauling the javadocs for the LuceneService

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode/pull/410


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #488 was SUCCESSFUL (with 1680 tests). Change made by John Blum.

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #488 was successful.
---
Scheduled with changes by John Blum.
1682 tests in total.

https://build.spring.io/browse/SGF-NAG-488/




--
Code Changes
--
John Blum (47849889740565e1b54642585c55f53ad450101a):

>SGF-598 - Review and polish.

John Blum (983c5212d2447de5bde3948ed6d54159f100dc78):

>SGF-598 - Add support for suspend and resume in GemfireTransactionManager.
>(cherry picked from commit a28534dd7aab629b7c5f459104860bb4ba3bef86)
>Signed-off-by: John Blum 



--
This message is automatically generated by Atlassian Bamboo

Re: Functions need reference to Cache

[Darrel Schneider]

A GemFireCache will be either a ClientCache or a Cache. If Functions always
execute on a member of the cluster then it this new getCache method should
return Cache. But if it is possible to execution a function in a client
then getCache should return GemFireCache.
GemFireCache extends RegionService and the only other implementation of
RegionService that is not a GemFireCache is ProxyCache. I don't think we
would ever have a Function executing in a ProxyCache (ProxyCache instances
only exist in a client and are used to pass different security info to the
server). If I'm wrong about this then you would want this method to return
RegionService.


On Thu, Mar 2, 2017 at 1:46 PM, Dan Smith  wrote:

> Yeah, there's even a PR for this - but it doesn't have tests. If anyone
> wants to pick that up and clean it up and add tests that would be great!
>
> https://github.com/apache/geode/pull/74
>
> -Dan
>
> On Thu, Mar 2, 2017 at 1:01 PM, John Blum  wrote:
>
> > Also keep in my mind if you are given a RegionFunctionContext (in cases
> > where the *Function* is executed "on a *Region*") then you have indirect
> > access to the cache...
> >
> > regionFunctionContext.getDataSet()
> >  > apache/geode/cache/execute/RegionFunctionContext.html#getDataSet-->
> > [1].getRegionService()
> >  > apache/geode/cache/Region.html#getRegionService-->
> > [2]
> >
> > GemFireCache is the only (direct) implementation of RegionService
> >  > RegionService.html>
> > [3]
> > that I am aware of.
> >
> > However, I generally agree that it would be useful to have direct access
> to
> > the GemFireCache from any FunctionContext.
> >
> > -j
> >
> > [1]
> > http://geode.apache.org/releases/latest/javadoc/org/
> > apache/geode/cache/execute/RegionFunctionContext.html#getDataSet--
> > [2]
> > http://geode.apache.org/releases/latest/javadoc/org/
> > apache/geode/cache/Region.html#getRegionService--
> > [3]
> > http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/
> > RegionService.html
> >
> >
> > On Thu, Mar 2, 2017 at 12:44 PM, Jinmei Liao  wrote:
> >
> > > I think I even see comments in the code stating "TODO: use the cache in
> > the
> > > FunctionContext when it becomes available".
> > >
> > > On Thu, Mar 2, 2017 at 12:30 PM, Kirk Lund  wrote:
> > >
> > > > I'm looking into a deadlock involving code under
> > > > org.apache.geode.management. Related to this, I'm also looking at all
> > of
> > > > the Functions that are implemented as part of the management layer.
> > > >
> > > > First thing every management Function appears to invoke is either
> > > > org.apache.geode.cache.CacheFactory.getAnyInstance() or
> > > > org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance()
> > to
> > > > get
> > > > a reference to the Cache.
> > > >
> > > > This method on CacheFactory seems to be frequently involved in
> > deadlocks
> > > in
> > > > general and I think we should find a way to deprecate it:
> > > >
> > > > /**
> > > >  * Gets an arbitrary open instance of {@link Cache} produced by an
> > > earlier
> > > > call to
> > > >  * {@link #create()}.
> > > >  *
> > > >  * @throws CacheClosedException if a cache has not been created or
> the
> > > only
> > > > created one is
> > > >  * {@link Cache#isClosed closed}
> > > >  */
> > > > public static synchronized Cache getAnyInstance() {
> > > >   GemFireCacheImpl instance = GemFireCacheImpl.getInstance();
> > > > 
> > > >
> > > > In an effort to prevent deadlocks and move away from statics and
> > > > singletons, I'd like to find a good alternative to this for
> Functions.
> > I
> > > > think adding this method to FunctionContext is the best solution:
> > > >
> > > > /**
> > > >  * Returns a reference to the Cache for which this function is
> > executing.
> > > >  */
> > > > public Cache getCache();
> > > >
> > > > Does this seem like a good solution? Is there any reason not to add
> > this
> > > to
> > > > the API?
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > >
> > > Jinmei
> > >
> >
> >
> >
> > --
> > -John
> > john.blum10101 (skype)
> >
>

[jira] [Commented] (GEODE-2488) Netstat command fails with OutOfMemoryError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2488:


Commit 6118d54c88401d52a9cd829252349a62e84a8afb in geode's branch 
refs/heads/develop from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6118d54 ]

GEODE-2488: Remove lsof from netstat command tests

Removed the --with-lsof option from netstat command to reduce the
command response size. Avoids OOME's on JVMs in the test environment
with small heaps.

The original tests with lsof have been retained, but annotated with
@Ignore.


> Netstat command fails with OutOfMemoryError
> ---
>
> Key: GEODE-2488
> URL: https://issues.apache.org/jira/browse/GEODE-2488
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>  Labels: MiscellaneousCommands, NetstatCommand, netstat
>
> Note: this can occur outside of dunit tests as well. Just using the gfsh 
> netstat command on locator or server with too little heap space will hit 
> this. See the 1st comment about not streaming the netstat output -- the 
> entire output is held in memory in a string and two byte arrays before 
> sending the result back from NetstatFunction.
> The JUnit controller JVM for NetstatDUnitTest fails with something like the 
> follow stack. The cause appears to be one of the DUnit VMs running out of 
> memory (see the OOME stack down further in this description.
> {noformat}
> org.junit.ComparisonFailure: [{"errorCode":505,"message":["Could not process 
> command due to GemFire error. Error occurred while executing netstat on 
> [server-1]"]}] expected:<[OK]> but was:<[ERROR]>
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:163)
>   at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne(NetstatDUnitTest.java:81)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>   at 
> sun.reflect.Deleg

[jira] [Resolved] (GEODE-1662) CI failure: IntegratedSecurityCacheLifecycleDistributedTest.initAndCloseTest

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1662.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> CI failure: IntegratedSecurityCacheLifecycleDistributedTest.initAndCloseTest
> 
>
> Key: GEODE-1662
> URL: https://issues.apache.org/jira/browse/GEODE-1662
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Bruce Schuchardt
>Assignee: Kirk Lund
>  Labels: CI, Flaky
> Fix For: 1.2.0
>
>
> org.junit.ComparisonFailure: expected:<[1]> but was:<[0]>
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at 
> com.gemstone.gemfire.security.IntegratedSecurityCacheLifecycleDistributedTest.verifyInitCloseInvoked(IntegratedSecurityCacheLifecycleDistributedTest.java:104)
>   at 
> com.gemstone.gemfire.security.IntegratedSecurityCacheLifecycleDistributedTest.initAndCloseTest(IntegratedSecurityCacheLifecycleDistributedTest.java:89)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.

Re: Functions need reference to Cache

[Dan Smith]

Yeah, there's even a PR for this - but it doesn't have tests. If anyone
wants to pick that up and clean it up and add tests that would be great!

https://github.com/apache/geode/pull/74

-Dan

On Thu, Mar 2, 2017 at 1:01 PM, John Blum  wrote:

> Also keep in my mind if you are given a RegionFunctionContext (in cases
> where the *Function* is executed "on a *Region*") then you have indirect
> access to the cache...
>
> regionFunctionContext.getDataSet()
>  apache/geode/cache/execute/RegionFunctionContext.html#getDataSet-->
> [1].getRegionService()
>  apache/geode/cache/Region.html#getRegionService-->
> [2]
>
> GemFireCache is the only (direct) implementation of RegionService
>  RegionService.html>
> [3]
> that I am aware of.
>
> However, I generally agree that it would be useful to have direct access to
> the GemFireCache from any FunctionContext.
>
> -j
>
> [1]
> http://geode.apache.org/releases/latest/javadoc/org/
> apache/geode/cache/execute/RegionFunctionContext.html#getDataSet--
> [2]
> http://geode.apache.org/releases/latest/javadoc/org/
> apache/geode/cache/Region.html#getRegionService--
> [3]
> http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/
> RegionService.html
>
>
> On Thu, Mar 2, 2017 at 12:44 PM, Jinmei Liao  wrote:
>
> > I think I even see comments in the code stating "TODO: use the cache in
> the
> > FunctionContext when it becomes available".
> >
> > On Thu, Mar 2, 2017 at 12:30 PM, Kirk Lund  wrote:
> >
> > > I'm looking into a deadlock involving code under
> > > org.apache.geode.management. Related to this, I'm also looking at all
> of
> > > the Functions that are implemented as part of the management layer.
> > >
> > > First thing every management Function appears to invoke is either
> > > org.apache.geode.cache.CacheFactory.getAnyInstance() or
> > > org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance()
> to
> > > get
> > > a reference to the Cache.
> > >
> > > This method on CacheFactory seems to be frequently involved in
> deadlocks
> > in
> > > general and I think we should find a way to deprecate it:
> > >
> > > /**
> > >  * Gets an arbitrary open instance of {@link Cache} produced by an
> > earlier
> > > call to
> > >  * {@link #create()}.
> > >  *
> > >  * @throws CacheClosedException if a cache has not been created or the
> > only
> > > created one is
> > >  * {@link Cache#isClosed closed}
> > >  */
> > > public static synchronized Cache getAnyInstance() {
> > >   GemFireCacheImpl instance = GemFireCacheImpl.getInstance();
> > > 
> > >
> > > In an effort to prevent deadlocks and move away from statics and
> > > singletons, I'd like to find a good alternative to this for Functions.
> I
> > > think adding this method to FunctionContext is the best solution:
> > >
> > > /**
> > >  * Returns a reference to the Cache for which this function is
> executing.
> > >  */
> > > public Cache getCache();
> > >
> > > Does this seem like a good solution? Is there any reason not to add
> this
> > to
> > > the API?
> > >
> >
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

[jira] [Resolved] (GEODE-2461) Remove unnecessary explicit dependencies

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-2461.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove unnecessary explicit dependencies
> 
>
> Key: GEODE-2461
> URL: https://issues.apache.org/jira/browse/GEODE-2461
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> These unused entries are potential candidates for removal from 
> gradle/dependency-versions.properties:
> * cdi-api.version
> * hadoop.version*
> * hbase.version (remove contains check from geode-assembly)
> * hibernate.version
> * hibernate-commons-annotations.version
> * hsqldb.version
> * jline.version
> * jsr305.version
> * paranamer.version
> * quartz.version
> * spymemcached.version? (remove testCompile from geode-core)
> These entries are actually for transitive dependencies and should have the 
> explicit dependency removed:
> * activation.version
> * asm.version (done)
> * cglib.version (remove testRuntime from test.gradle)
> * classmate (remove compile from geode-web-api)
> * mortbay-jetty-servlet-api.version? (remove provided from geode-pulse)
> * scala.version (remove compile from geode-web-api)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2558) Upgrade mockito dependency

[Srikanth Manvi (JIRA)]

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

Srikanth Manvi commented on GEODE-2558:
---

Hi [~klund],

Has work started on this ? I would love to contribute on this, with someones 
guidance.

> Upgrade mockito dependency
> --
>
> Key: GEODE-2558
> URL: https://issues.apache.org/jira/browse/GEODE-2558
> Project: Geode
>  Issue Type: Wish
>  Components: build, tests
>Reporter: Kirk Lund
>
> Mockito should be upgrade from 1.x to 2.x.
> 1.10.19 (Dec, 2014) <-- current version
> 2.7.11 (Feb 2017)
> This requires updating Powermock as well.
> Changes to dependency-versions.properties:
> {noformat}
> -mockito-core.version = 1.10.19
> +mockito-core.version = 2.7.11
> ...
> -powermock.version = 1.6.6
> +powermock.version = 1.7.0RC2
> {noformat}
> The upgrade from Mockito 1.x to 2.x includes breaking APIs. Even after 
> updating the APIs to compile, I still see a number of unit tests that use 
> Mockito failing. These tests span all of the components in Geode so it's a 
> non-trivial upgrade.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jared Stewart]

> On March 2, 2017, 6:44 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
> > Lines 154 (patched)
> > 
> >
> > I don't think that we ought to manually delete the workingDir.  If 
> > someone is using a temporaryFolder (which I think is the normal use case), 
> > then the deletion will happen automatically.  If they aren't using a 
> > temporary folder, then deleting the workingDir seems dangerous.
> 
> Jinmei Liao wrote:
> this is there so that when we are writing test using this rule alone, we 
> don't need to have the have a temperoaryFolder rule along side with it. The 
> rule itself handles creating the temeroray folder and delete it afterwards. 
> The deletion happens in the after() block, so it should be pretty safe.
> 
> Jared Stewart wrote:
> As a user of this rule, the following would seem like a reasonable thing 
> to do:
> 
> ```
> private final File workingDir = new File(".");
> 
> @Rule
> ServerStarterRule serverStarterRule = new ServerStarterRule(workingDir);
> ```
> 
> 
> Yet it would end up deleting part of the user's geode checkout.  Perhaps 
> we should have separate constructors or factory methods for using this rule 
> alone vs. using it through LocatorServerStarterRule.  That way, when used 
> alone, it can create its own temporary folder so that a user doesn't have to 
> worry about it.
> 
> Jinmei Liao wrote:
> The reason behind this refactoring is that the normal use case is that 
> user don't need to use a temporaryFolder with this rule. the rule handles the 
> create/deleting the temp folder for you, like this:
> 
>  @Rule
>   public ServerStarterRule serverStarterRule = new ServerStarterRule();
>  
>  @Test
>  public void test(){
>Server server = serverStarterRule.startServer();
>File workingDir = server.getWorkingDir();
>// verfify the working dir
>  }
>  
>  And the rule will handle deleting the working dir created afterwards. 
> Maybe you are suggesting that if user passes in a workingDir, then you are 
> responsible of deleting it, the rule won't?

Yes, precisely.  I think the creator of the directory should be the one 
responsible for deleting it.


- Jared


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167712
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/ja

Re: [GitHub] geode pull request #404: Geode 2469

[Michael Stolz]

We generally do use separate regions for separate data types that have
different qualities of service.
As long as we don't think there will be a proliferation of regions due to
the ":" convention it shouldn't be too bad.
There is an issue with dynamic creation of regions in general.
New nodes that come up after the Region was dynamically created won't know
about the Region and won't create it.
That's the main reason I tend to avoid dynamic Region creation in my code.


--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Thu, Mar 2, 2017 at 4:23 PM, ggreen  wrote:

> Github user ggreen commented on a diff in the pull request:
>
> https://github.com/apache/geode/pull/404#discussion_r104033312
>
> --- Diff: 
> geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java
> ---
> @@ -259,6 +307,16 @@ public void 
> createRemoteRegionReferenceLocally(ByteArrayWrapper
> key, RedisDataTy
>
>private Region getOrCreateRegion0(ByteArrayWrapper key,
> RedisDataType type,
>ExecutionHandlerContext context, boolean addToMeta) {
> +
> +String regionName = key.toString();
> +
> +// check if type is hash TODO: remove
> --- End diff --
>
> Hello @galen-pivotal ,
>
> You mean why do we need to create a region for an object, correct?
> If you mean that, then yes, I guess we could just use the same
> ReDiS_HASH region for objects and non-objects. Of course, there are pros
> and cons for each approach.
>
> Prior to this pull request, the Redis adapter created objects for all
> HASH keys. I originally liked the idea of limiting the creation of regions
> to just HASH objects. Having a separate region when objects are used can
> provide additional flexibility.  For example, we could pre-define the
> region with unique definitions based on a given use case.
>
> While testing with Spring Data Redis example, I created a "companies"
> region with my desired properties that were totally over my control. These
> regions for objects could be managed separately from the default ReDiS_HASH
> region. For example, we could different data policies, disk stores,
> listeners, etc.
>
> What do you think?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

[GitHub] geode pull request #404: Geode 2469

[ggreen]

Github user ggreen commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r104033312
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java ---
@@ -259,6 +307,16 @@ public void 
createRemoteRegionReferenceLocally(ByteArrayWrapper key, RedisDataTy
 
   private Region getOrCreateRegion0(ByteArrayWrapper key, 
RedisDataType type,
   ExecutionHandlerContext context, boolean addToMeta) {
+
+String regionName = key.toString();
+
+// check if type is hash TODO: remove
--- End diff --

Hello @galen-pivotal ,

You mean why do we need to create a region for an object, correct?
If you mean that, then yes, I guess we could just use the same ReDiS_HASH 
region for objects and non-objects. Of course, there are pros and cons for each 
approach.

Prior to this pull request, the Redis adapter created objects for all HASH 
keys. I originally liked the idea of limiting the creation of regions to just 
HASH objects. Having a separate region when objects are used can provide 
additional flexibility.  For example, we could pre-define the region with 
unique definitions based on a given use case.

While testing with Spring Data Redis example, I created a "companies" 
region with my desired properties that were totally over my control. These 
regions for objects could be managed separately from the default ReDiS_HASH 
region. For example, we could different data policies, disk stores, listeners, 
etc. 

What do you think?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GEODE-1434) Update native client source headers

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-1434:
--

Based on the {{rat}} reports this task is complete.

> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (GEODE-1434) Update native client source headers

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1434.


> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-1434) Update native client source headers

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1434.
--
Resolution: Fixed

> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (GEODE-2312) Hook rat into cmake build

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-2312.


> Hook rat into cmake build
> -
>
> Key: GEODE-2312
> URL: https://issues.apache.org/jira/browse/GEODE-2312
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should invoke rat from the cmake build to ensure that all files have 
> proper ASF headers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (GEODE-2312) Hook rat into cmake build

[Anthony Baker (JIRA)]

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

Anthony Baker edited comment on GEODE-2312 at 3/2/17 9:01 PM:
--

{{rat}} has been added to the travis-ci checks:  
https://github.com/apache/geode-native/blob/develop/.travis.yml#L30.  This 
should be sufficient for now.


was (Author: amb):
{{rat}} has been added to the travis-ci checks:  
https://github.com/apache/geode-native/blob/develop/.travis.yml#L30.

> Hook rat into cmake build
> -
>
> Key: GEODE-2312
> URL: https://issues.apache.org/jira/browse/GEODE-2312
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should invoke rat from the cmake build to ensure that all files have 
> proper ASF headers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2312) Hook rat into cmake build

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2312.
--
Resolution: Fixed

> Hook rat into cmake build
> -
>
> Key: GEODE-2312
> URL: https://issues.apache.org/jira/browse/GEODE-2312
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should invoke rat from the cmake build to ensure that all files have 
> proper ASF headers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Functions need reference to Cache

[John Blum]

Also keep in my mind if you are given a RegionFunctionContext (in cases
where the *Function* is executed "on a *Region*") then you have indirect
access to the cache...

regionFunctionContext.getDataSet()

[1].getRegionService()

[2]

GemFireCache is the only (direct) implementation of RegionService

[3]
that I am aware of.

However, I generally agree that it would be useful to have direct access to
the GemFireCache from any FunctionContext.

-j

[1]
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/execute/RegionFunctionContext.html#getDataSet--
[2]
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/Region.html#getRegionService--
[3]
http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/RegionService.html


On Thu, Mar 2, 2017 at 12:44 PM, Jinmei Liao  wrote:

> I think I even see comments in the code stating "TODO: use the cache in the
> FunctionContext when it becomes available".
>
> On Thu, Mar 2, 2017 at 12:30 PM, Kirk Lund  wrote:
>
> > I'm looking into a deadlock involving code under
> > org.apache.geode.management. Related to this, I'm also looking at all of
> > the Functions that are implemented as part of the management layer.
> >
> > First thing every management Function appears to invoke is either
> > org.apache.geode.cache.CacheFactory.getAnyInstance() or
> > org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance() to
> > get
> > a reference to the Cache.
> >
> > This method on CacheFactory seems to be frequently involved in deadlocks
> in
> > general and I think we should find a way to deprecate it:
> >
> > /**
> >  * Gets an arbitrary open instance of {@link Cache} produced by an
> earlier
> > call to
> >  * {@link #create()}.
> >  *
> >  * @throws CacheClosedException if a cache has not been created or the
> only
> > created one is
> >  * {@link Cache#isClosed closed}
> >  */
> > public static synchronized Cache getAnyInstance() {
> >   GemFireCacheImpl instance = GemFireCacheImpl.getInstance();
> > 
> >
> > In an effort to prevent deadlocks and move away from statics and
> > singletons, I'd like to find a good alternative to this for Functions. I
> > think adding this method to FunctionContext is the best solution:
> >
> > /**
> >  * Returns a reference to the Cache for which this function is executing.
> >  */
> > public Cache getCache();
> >
> > Does this seem like a good solution? Is there any reason not to add this
> to
> > the API?
> >
>
>
>
> --
> Cheers
>
> Jinmei
>



-- 
-John
john.blum10101 (skype)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

> On March 2, 2017, 6:44 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
> > Lines 154 (patched)
> > 
> >
> > I don't think that we ought to manually delete the workingDir.  If 
> > someone is using a temporaryFolder (which I think is the normal use case), 
> > then the deletion will happen automatically.  If they aren't using a 
> > temporary folder, then deleting the workingDir seems dangerous.
> 
> Jinmei Liao wrote:
> this is there so that when we are writing test using this rule alone, we 
> don't need to have the have a temperoaryFolder rule along side with it. The 
> rule itself handles creating the temeroray folder and delete it afterwards. 
> The deletion happens in the after() block, so it should be pretty safe.
> 
> Jared Stewart wrote:
> As a user of this rule, the following would seem like a reasonable thing 
> to do:
> 
> ```
> private final File workingDir = new File(".");
> 
> @Rule
> ServerStarterRule serverStarterRule = new ServerStarterRule(workingDir);
> ```
> 
> 
> Yet it would end up deleting part of the user's geode checkout.  Perhaps 
> we should have separate constructors or factory methods for using this rule 
> alone vs. using it through LocatorServerStarterRule.  That way, when used 
> alone, it can create its own temporary folder so that a user doesn't have to 
> worry about it.

The reason behind this refactoring is that the normal use case is that user 
don't need to use a temporaryFolder with this rule. the rule handles the 
create/deleting the temp folder for you, like this:

 @Rule
  public ServerStarterRule serverStarterRule = new ServerStarterRule();
 
 @Test
 public void test(){
   Server server = serverStarterRule.startServer();
   File workingDir = server.getWorkingDir();
   // verfify the working dir
 }
 
 And the rule will handle deleting the working dir created afterwards. Maybe 
you are suggesting that if user passes in a workingDir, then you are 
responsible of deleting it, the rule won't?


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167712
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployComma

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Kirk Lund]

> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
> > Lines 67 (patched)
> > 
> >
> > Wouldn't it be better to just Chain TemporaryFolder or 
> > DistributedTemporaryFolder with this Rule? Or maybe pass 
> > TemporaryFolder.getRoot() into the constructor on this Rule, and then let 
> > TemporaryFolder handle the before/after for itself. Now we'll have two 
> > rules that provide temporary directories.
> 
> Jinmei Liao wrote:
> We were doing that before, but rules inside rules are not behaving 
> correctly. We need to manually call the before and after the rules we used. 
> Will look into this more.
> 
> Jared Stewart wrote:
> This seems like the intended use case of RuleChain:
> 
> ```
> TemporaryFolder temporaryFolder = new TemporaryFolder();
> LocatorServerStarterRule locatorServerStarterRule = new 
> LocatorServerStarterRule(temporaryFolder);
> 
> @Rule
> RuleChain ruleChain = 
> RuleChain.outerRule(temporaryFolder).aroundRule(locatorServerStarterRule);
> ```
> 
> Still, the above requires a lot of boilerplate, and I think makes the 
> rule harder to use.  Just throwing out an idea.

You can also internally chain embedded rules. Not sure why that was causing 
problems before, but org.apache.geode.test.junit.rules.ExpectedTimeoutRule 
contains and delegates to an ExpectedException rule. The implementation has to 
contain something like one of the following...
```java
  @Override
  public Statement apply(final Statement base, final Description description) {
Statement next = this.delegate.apply(base, description); <-- inserts the 
delegate
return new ExpectedTimeoutStatement(next); <-- wraps the delegate which 
wraps the next rule (or test if last rule)
  }
```
Or...
```java
  private Statement statement(final Statement base) {
return new Statement() {
  @Override
  public void evaluate() throws Throwable {
before();
try {
  base.evaluate(); <-- invokes the next rule or the test if this is the 
last rule
} finally {
  after();
}
  }
};
  }
```


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167694
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755

[jira] [Commented] (GEODE-2312) Hook rat into cmake build

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2312:
--

{{rat}} has been added to the travis-ci checks:  
https://github.com/apache/geode-native/blob/develop/.travis.yml#L30.

> Hook rat into cmake build
> -
>
> Key: GEODE-2312
> URL: https://issues.apache.org/jira/browse/GEODE-2312
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should invoke rat from the cmake build to ensure that all files have 
> proper ASF headers.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (GEODE-2502) Resolve ACE license compatibility

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-2502.


> Resolve ACE license compatibility
> -
>
> Key: GEODE-2502
> URL: https://issues.apache.org/jira/browse/GEODE-2502
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Priority: Blocker
>
> See LEGAL-289.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2502) Resolve ACE license compatibility

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-2502.
--
Resolution: Not A Problem

> Resolve ACE license compatibility
> -
>
> Key: GEODE-2502
> URL: https://issues.apache.org/jira/browse/GEODE-2502
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Priority: Blocker
>
> See LEGAL-289.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2502) Resolve ACE license compatibility

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-2502:
--

ACE has been added to the CatA list:  
https://www.apache.org/legal/resolved#category-a.

> Resolve ACE license compatibility
> -
>
> Key: GEODE-2502
> URL: https://issues.apache.org/jira/browse/GEODE-2502
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Priority: Blocker
>
> See LEGAL-289.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Functions need reference to Cache

[Jinmei Liao]

I think I even see comments in the code stating "TODO: use the cache in the
FunctionContext when it becomes available".

On Thu, Mar 2, 2017 at 12:30 PM, Kirk Lund  wrote:

> I'm looking into a deadlock involving code under
> org.apache.geode.management. Related to this, I'm also looking at all of
> the Functions that are implemented as part of the management layer.
>
> First thing every management Function appears to invoke is either
> org.apache.geode.cache.CacheFactory.getAnyInstance() or
> org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance() to
> get
> a reference to the Cache.
>
> This method on CacheFactory seems to be frequently involved in deadlocks in
> general and I think we should find a way to deprecate it:
>
> /**
>  * Gets an arbitrary open instance of {@link Cache} produced by an earlier
> call to
>  * {@link #create()}.
>  *
>  * @throws CacheClosedException if a cache has not been created or the only
> created one is
>  * {@link Cache#isClosed closed}
>  */
> public static synchronized Cache getAnyInstance() {
>   GemFireCacheImpl instance = GemFireCacheImpl.getInstance();
> 
>
> In an effort to prevent deadlocks and move away from statics and
> singletons, I'd like to find a good alternative to this for Functions. I
> think adding this method to FunctionContext is the best solution:
>
> /**
>  * Returns a reference to the Cache for which this function is executing.
>  */
> public Cache getCache();
>
> Does this seem like a good solution? Is there any reason not to add this to
> the API?
>



-- 
Cheers

Jinmei

Re: Functions need reference to Cache

[Jared Stewart]

I agree this would be useful, and I think it already has an open GEODE
ticket:
https://issues.apache.org/jira/plugins/servlet/mobile#issue/GEODE-393

On Mar 2, 2017 12:30 PM, "Kirk Lund"  wrote:

> I'm looking into a deadlock involving code under
> org.apache.geode.management. Related to this, I'm also looking at all of
> the Functions that are implemented as part of the management layer.
>
> First thing every management Function appears to invoke is either
> org.apache.geode.cache.CacheFactory.getAnyInstance() or
> org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance() to
> get
> a reference to the Cache.
>
> This method on CacheFactory seems to be frequently involved in deadlocks in
> general and I think we should find a way to deprecate it:
>
> /**
>  * Gets an arbitrary open instance of {@link Cache} produced by an earlier
> call to
>  * {@link #create()}.
>  *
>  * @throws CacheClosedException if a cache has not been created or the only
> created one is
>  * {@link Cache#isClosed closed}
>  */
> public static synchronized Cache getAnyInstance() {
>   GemFireCacheImpl instance = GemFireCacheImpl.getInstance();
> 
>
> In an effort to prevent deadlocks and move away from statics and
> singletons, I'd like to find a good alternative to this for Functions. I
> think adding this method to FunctionContext is the best solution:
>
> /**
>  * Returns a reference to the Cache for which this function is executing.
>  */
> public Cache getCache();
>
> Does this seem like a good solution? Is there any reason not to add this to
> the API?
>

Re: Functions need reference to Cache

[Anthony Baker]

> On Mar 2, 2017, at 12:30 PM, Kirk Lund  wrote:
> 
> 
> In an effort to prevent deadlocks and move away from statics and
> singletons, I'd like to find a good alternative to this for Functions. I
> think adding this method to FunctionContext is the best solution:
> 
> /**
> * Returns a reference to the Cache for which this function is executing.
> */
> public Cache getCache();
> 
> Does this seem like a good solution? Is there any reason not to add this to
> the API?

Someone else likes your idea too:

https://issues.apache.org/jira/browse/GEODE-393

Anthony

Functions need reference to Cache

[Kirk Lund]

I'm looking into a deadlock involving code under
org.apache.geode.management. Related to this, I'm also looking at all of
the Functions that are implemented as part of the management layer.

First thing every management Function appears to invoke is either
org.apache.geode.cache.CacheFactory.getAnyInstance() or
org.apache.geode.cache.internal.cache.GemFireCacheImpl getInstance() to get
a reference to the Cache.

This method on CacheFactory seems to be frequently involved in deadlocks in
general and I think we should find a way to deprecate it:

/**
 * Gets an arbitrary open instance of {@link Cache} produced by an earlier
call to
 * {@link #create()}.
 *
 * @throws CacheClosedException if a cache has not been created or the only
created one is
 * {@link Cache#isClosed closed}
 */
public static synchronized Cache getAnyInstance() {
  GemFireCacheImpl instance = GemFireCacheImpl.getInstance();


In an effort to prevent deadlocks and move away from statics and
singletons, I'd like to find a good alternative to this for Functions. I
think adding this method to FunctionContext is the best solution:

/**
 * Returns a reference to the Cache for which this function is executing.
 */
public Cache getCache();

Does this seem like a good solution? Is there any reason not to add this to
the API?

[GitHub] geode issue #404: Geode 2469

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/404
  
@ggreen
Is there any reason we need to create objects rather than just storing 
under the given string?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 57243: GEODE-2416: Collect together artifacts from individual servers into a single zip file

[Jinmei Liao]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57243/
---

(Updated March 2, 2017, 7:26 p.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Changes
---

precheckin successful. I rebased the changeset to the current develop, so that 
you won't be getting the changes of the rules refactoring. hopefully the 
changeset would be smaller.


Repository: geode


Description
---

GEODE-2414: Determine a mechanism to stream a zip file from server to locator
GEODE-2415: Write a function to return a zip file for a single server
GEODE-2418: enable gfsh to download file from http connection
GEODE-2267: add validation to the arguments and include export stats in the 
command
GEODE-2267: use the config to determine where the logs and stats are
GEODE-2267: Enhance server/locator startup rules to include workingDir

What's not done in this batch:
1. If you are exporting without http connection, exported zip will be left on 
the loator's working dir, currently we don't have a cleanup mechanism to delete 
them.
2. long running task may timeout the http connection. No test around this 
scenario.
3. No warning to the user if they are exporting a large quantity of logs.
4. we are exporting all the .log and .gfs files and only those files. Other 
file extensions are ignored.
5. merge-log option is ignored


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/logging/GemFireLevel.java 
cffd162687573c9f7861bc2ada1076293c2e0a57 
  
geode-core/src/main/java/org/apache/geode/internal/logging/InternalLogWriter.java
 661fce99f01a890b727daf7dc591316d1d8982fb 
  geode-core/src/main/java/org/apache/geode/internal/logging/LogService.java 
0ad7d848a05a0104ce01652b1fb628f2cff1b2d1 
  
geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveHandler.java
 03b0f898ad30b6b088108fa0187b0a5a750ed6dc 
  geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
a20fba5a1b9fa185283bd7c60c4ade77345ed4ac 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptor.java
 de24727819856d180a69ed0021c21aa016e71712 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java
 11d74c13311923357e82318b32bf0342e156e0c6 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java 
8cd098d9719774c49efcf28d1d5ecdcd345687fc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandRequest.java
 b0242c9e8ee656001cf76155f4e727ece07666a2 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
 bbf0542b80469e11d21a2ed56f52ef9e647e91ea 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/LogFileFunction.java
 41ffeb40b4dd09ed2bf7eb4ef2cd516001927025 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 c536e8e99ef32043d9caf267dd563ee2d05b6e50 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
 b53c53f91ed63a01bfaa1232d9e194481ae45664 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ExportLogsCacheWriter.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ExportLogsRepository.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogFilter.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogLevelExtractor.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/MergeLogs.java
 8d2ef4599337cb091da6f26c6034b1a71311148d 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/ZipUtils.java
 81161d6f3e2539ca3d09765e99b891d1522da302 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
 ac912c82c873c443dd268f07e8874b5bd18fdd0b 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java
 fa052489772e3e03eb865d17dbbcb7e227813c42 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/shell/RestHttpOperationInvoker.java
 82b2b1fc0d2c8952835b0101c413161d39f361dc 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/shell/SimpleHttpOperationInvoker.java
 dcda27bef61bad1d7caf1fe1a99063f99d768819 
  
geode-core/src/test/java/org/apache/geode/internal/statistics/SimpleStatSamplerIntegrationTest.java
 167fa3d07802136ea68ec2f4f54e7c4716ea938a 
  
geode-core/src/test/java/org/a

[jira] [Commented] (GEODE-2267) Add gfsh command to export stat files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2267:


Commit 9766cf2334a8f84c5b90fc29d8e73fd1c49858dc in geode's branch 
refs/heads/develop from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9766cf2 ]

GEODE-2267: Enhance server/locator startup rules to include workingDir - add 
missed checkin


> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>Assignee: Kirk Lund
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57243: GEODE-2416: Collect together artifacts from individual servers into a single zip file

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57243/#review167709
---



I'm going to publish what I have so far for review. This is for page 1 of the 
diffs.


geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java
Lines 40 (patched)


This is an internal class. Can we just delete methods like this instead of 
deprecating it?



geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
Lines 308 (patched)


You should create CliUtilTest or CliUtilIntegrationTest and write some 
tests for these new methods.



geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandRequest.java
Lines 43 (patched)


I recommend making this final and alter the constructor:
```java
this.downloadFile = metaData != null && metaData.isFileDownloadOverHttp();
```



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
Line 782 (original), 694 (patched)


We should not modify this method in place (in MiscellaneousCommands) 
without extracting it and introducing unit tests.

Example:

1) extract this command to its own class "ExportLogsCommand"

2) extract the guts of this method to another class (maybe called 
ExportLogs)

ExportLogs becomes a simple class that does not know anything about GFSH or 
CLI parsing or those annotations. It just knows how to do the actual work based 
on arguments passed to its constructor.

ExportLogsCommand becomes a simple class that uses ExportLogs within the 
context of GFSH and handles all of the CLI annotations.

Then we can write a true mocking UnitTest for ExportLogs and test this 
class and its functionality in isolation from GFSH. All classes should end up 
being testable with a true UnitTest and classes should be refactored to follow 
good OOP practices (single responsibility, etc). This is not an OOP class as 
currently written.

This method should also be broken down into nice small methods that can be 
tested and tests should be written for them.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
Line 810 (original), 728 (patched)


At some point we need to delete CliUtil and CacheFactory.getAnyInstance and 
start passing around instances instead of using statics and singletons. This 
forces us into doing all of our testing with integration tests instead of unit 
tests.

It's sad to see so many static calls in this method that are invoking 
getAnyInstance



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
Line 833 (original), 733 (patched)


At a minimum, I'd hoist this "Region region =" out of the for-loop and 
invoke it just once.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
Line 872 (original), 749 (patched)


Fix typo "Recieved" and change to use log4j parms:
```java
logger.info("Received zip file from member {}: {}", server.getId(), 
zipFile);
```



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
Lines 57 (patched)


This class should be a Function that uses another class called LogExporter.

LogExporter should be a class that follows solid OOP principles and has a 
new UnitTest that uses Mockito to test it in isolation.

ExportLogsFunction then becomes an integration class that uses LogExporter 
within the context of a Function.



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
Lines 119 (patched)


Why is this public? Is this called from other classes?



geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
Lines 121 (patched)


Let's get rid of these singleton calls. Make the methods non-static (and 
preferrably private). 

Call GemFireCacheImpl.getInstance() once and store it in a member variable. 
Then have all of the other methods use that var instead of hitting 
GemFireCacheImpl.getInstance() repeatedly.

We want to remove all statics and singletons so that we can start writing 
good unit tests.



geode-core/src/main/java/org/

Re: Review Request 57249: GEODE-2488: Remove lsof from netstat command tests

[Kevin Duling]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57249/#review167718
---


Ship it!




Ship It!

- Kevin Duling


On March 2, 2017, 11:12 a.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57249/
> ---
> 
> (Updated March 2, 2017, 11:12 a.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removed the --with-lsof option from netstat command to reduce the
> command response size. Avoids OOME's on JVMs in the test environment
> with small heaps.
> 
> The original tests with lsof have been retained, but annotated with
> @Ignore.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
>  c6248e052ea8d8579c4f5b2b4de9ec74dca30e72 
> 
> 
> Diff: https://reviews.apache.org/r/57249/diff/1/
> 
> 
> Testing
> ---
> 
> Tested locally on JVMs with small heap to verify there are no OOMEs
> Precheckin has been started.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Review Request 57249: GEODE-2488: Remove lsof from netstat command tests

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57249/
---

Review request for geode, Jinmei Liao, Jared Stewart, Kevin Duling, and Kirk 
Lund.


Repository: geode


Description
---

Removed the --with-lsof option from netstat command to reduce the
command response size. Avoids OOME's on JVMs in the test environment
with small heaps.

The original tests with lsof have been retained, but annotated with
@Ignore.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
 c6248e052ea8d8579c4f5b2b4de9ec74dca30e72 


Diff: https://reviews.apache.org/r/57249/diff/1/


Testing
---

Tested locally on JVMs with small heap to verify there are no OOMEs
Precheckin has been started.


Thanks,

Ken Howe

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
> > Lines 66 (patched)
> > 
> >
> > I think it would best if you can keep this self-contained as a 
> > ClassRule instead of invoking a rule method in BeforeClass:
> > ```java
> >   @ClassRule
> >   public static ServerStarterRule serverStarter = new 
> > ServerStarterRule().startServer(properties);
> > ```
> > Or (this matches the new pattern than JUnit folks are pushing for 
> > complex rules):
> > ```java
> >   @ClassRule
> >   public static ServerStarterRule serverStarter = 
> > ServerStarterRule.builder().startServer(properties).build();
> > ```
> > And then change startServer to return this (ServerStarterRule).

Good idea. Will enhance this more in the next round.


> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
> > Line 80 (original), 80 (patched)
> > 
> >
> > I would override startLocatorVM to have a flavor that doesn't require 
> > new Properties.
> > ```java
> > locator = lsRule.startLocatorVM(0);
> > ```

good idea. It was added at one point.


> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
> > Line 399 (original), 399 (patched)
> > 
> >
> > I know I mentioned it before, but I really don't like seeing a Rule 
> > used as not-a-Rule.
> > 
> > It would be much cleaner to create a ServerStarter class. Then use 
> > ServerStarter directly where you don't need a Rule and use 
> > ServerStarterRule only where you need a Rule (ie, when JUnit lifecycle is 
> > responsible for invoking before and after instead of invoking directly like 
> > this).

We usually wouldn't need to do this. This is an old tests that is not using 
LocatorServerStarterRule, and I need a quick a way to start a server in the vm. 
I will add a note in the test saying this is not a recommended usage.


> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
> > Lines 59 (patched)
> > 
> >
> > This could all be moved into a builder on the Rule. See 
> > org.junit.rules.Timeout and org.apache.geode.management.ManagementTestRule:
> > ```java
> >   @ClassRule
> >   public static ServerStarterRule serverRule = 
> > ServerStarterRule.builder()
> > .setProperty(SECURITY_MANAGER, 
> > SimpleTestSecurityManager.class.getName())
> > .setProperty(JMX_MANAGER_PORT, jmxManagerPort + "")
> > .setProperty(JMX_MANAGER_PORT, jmxManagerPort + "")
> > .startServer()
> > .build();
> > ```
> > This is the pattern/style recommended for complex rules (it's not my 
> > invention).

Good idea. Will consider this in the next round of refactoring.


> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
> > Lines 67 (patched)
> > 
> >
> > Wouldn't it be better to just Chain TemporaryFolder or 
> > DistributedTemporaryFolder with this Rule? Or maybe pass 
> > TemporaryFolder.getRoot() into the constructor on this Rule, and then let 
> > TemporaryFolder handle the before/after for itself. Now we'll have two 
> > rules that provide temporary directories.

We were doing that before, but rules inside rules are not behaving correctly. 
We need to manually call the before and after the rules we used. Will look into 
this more.


> On March 2, 2017, 6:39 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
> > Lines 76 (patched)
> > 
> >
> > I've this behave differently on different operating systems and 
> > misbehave in general. It creates the illusion to the next developer that 
> > this system property is mutable, and then it can be nightmare to debug when 
> > they use a JDK API that theoretically uses "user.dir" but still ends up 
> > using the original "user.dir" -- I would do everything we can to eliminate 
> > usage of "user.dir" or back it into a corner (one single line of code in 
> > all of Geode).
> > 
> > We can alter any Geode code that relies on relative paths to have 
> > absolute paths always passed into them. Then this problem goes away. 
> > 
> > Or at the very least it pu

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

> On March 2, 2017, 6:44 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
> > Lines 154 (patched)
> > 
> >
> > I don't think that we ought to manually delete the workingDir.  If 
> > someone is using a temporaryFolder (which I think is the normal use case), 
> > then the deletion will happen automatically.  If they aren't using a 
> > temporary folder, then deleting the workingDir seems dangerous.

this is there so that when we are writing test using this rule alone, we don't 
need to have the have a temperoaryFolder rule along side with it. The rule 
itself handles creating the temeroray folder and delete it afterwards. The 
deletion happens in the after() block, so it should be pretty safe.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167712
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
> 7cc1eea2e26b176b570111bccdb8

[jira] [Commented] (GEODE-2488) Netstat command fails with OutOfMemoryError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2488:


Commit 9e7edbf1c3e9612b9862671419f36c26b52e43e7 in geode's branch 
refs/heads/feature/GEODE-2488 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9e7edbf ]

GEODE-2488: Remove lsof from netstat command tests

Removed the --with-lsof option from netstat command to reduce the
command response size. Avoids OOME's on JVMs in the test environment
with small heaps.

The original tests with lsof have been retained, but annotated with
@Ignore.


> Netstat command fails with OutOfMemoryError
> ---
>
> Key: GEODE-2488
> URL: https://issues.apache.org/jira/browse/GEODE-2488
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>  Labels: MiscellaneousCommands, NetstatCommand, netstat
>
> Note: this can occur outside of dunit tests as well. Just using the gfsh 
> netstat command on locator or server with too little heap space will hit 
> this. See the 1st comment about not streaming the netstat output -- the 
> entire output is held in memory in a string and two byte arrays before 
> sending the result back from NetstatFunction.
> The JUnit controller JVM for NetstatDUnitTest fails with something like the 
> follow stack. The cause appears to be one of the DUnit VMs running out of 
> memory (see the OOME stack down further in this description.
> {noformat}
> org.junit.ComparisonFailure: [{"errorCode":505,"message":["Could not process 
> command due to GemFire error. Error occurred while executing netstat on 
> [server-1]"]}] expected:<[OK]> but was:<[ERROR]>
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:163)
>   at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne(NetstatDUnitTest.java:81)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:37)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>   at 
> sun.re

[GitHub] geode issue #404: Geode 2469

[ggreen]

Github user ggreen commented on the issue:

https://github.com/apache/geode/pull/404
  
**RE: "huser:1000**

The intent is to detect the use of objects in the Redis HASH commands. The 
character ":" will appear in the key if an object is used (note: this is unique 
for HASH commands). The format of the key will be object:key. 

So if a HASH command was used with the key "huser:1000", this should have 
resulted in an "huser" region being created  @with a key of "1000". If this did 
not happen, this is a bug.

The /ReDiS_HASH region should be used in cases where ":" does not exist in 
the key (because this is not necessarily an object).

I can fix this along with the indicated issues (2-4)



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Ken Howe]

> On March 2, 2017, 6:31 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
> > Line 140 (original), 114 (patched)
> > 
> >
> > Why is arg changed from 0 to -1? See comment on ServerStartRule
> 
> Jinmei Liao wrote:
> "0" has some confusing meanings. In our product code, sometimes if we set 
> a port to 0, it means "use random port". Here I use "-1" to emphasize the 
> fact that I don't want this server to connect to any locator, it's a 
> standalone server.

I agree with the intent, but without code to back up the use of -1, it's just a 
magic number that that we now need to infer the intent thru code inspection. 

Maybe enforce the standalone server usage by providing a startServerVM variant 
using a boolean argument, e.g. standaloneServer = true


- Ken


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167703
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/te

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jared Stewart]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167712
---




geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
Lines 154 (patched)


I don't think that we ought to manually delete the workingDir.  If someone 
is using a temporaryFolder (which I think is the normal use case), then the 
deletion will happen automatically.  If they aren't using a temporary folder, 
then deleting the workingDir seems dangerous.


- Jared Stewart


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
> 7cc1eea2e26b176b570111bccdb8914e19528ecf 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
> 4aa2c69389dce4650cf476f4e8decebddfc36736 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  b5ddee666c52fe39deb015c6e2aa57e5b21e4f20 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/QueryNamesOverHttpDUnitTest.java
>  1a19e5e5ca90c248

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Kirk Lund]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167694
---




geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
Lines 66 (patched)


I think it would best if you can keep this self-contained as a ClassRule 
instead of invoking a rule method in BeforeClass:
```java
  @ClassRule
  public static ServerStarterRule serverStarter = new 
ServerStarterRule().startServer(properties);
```
Or (this matches the new pattern than JUnit folks are pushing for complex 
rules):
```java
  @ClassRule
  public static ServerStarterRule serverStarter = 
ServerStarterRule.builder().startServer(properties).build();
```
And then change startServer to return this (ServerStarterRule).



geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
Line 80 (original), 80 (patched)


I would override startLocatorVM to have a flavor that doesn't require new 
Properties.
```java
locator = lsRule.startLocatorVM(0);
```



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
Line 399 (original), 399 (patched)


I know I mentioned it before, but I really don't like seeing a Rule used as 
not-a-Rule.

It would be much cleaner to create a ServerStarter class. Then use 
ServerStarter directly where you don't need a Rule and use ServerStarterRule 
only where you need a Rule (ie, when JUnit lifecycle is responsible for 
invoking before and after instead of invoking directly like this).



geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
Lines 59 (patched)


This could all be moved into a builder on the Rule. See 
org.junit.rules.Timeout and org.apache.geode.management.ManagementTestRule:
```java
  @ClassRule
  public static ServerStarterRule serverRule = ServerStarterRule.builder()
.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName())
.setProperty(JMX_MANAGER_PORT, jmxManagerPort + "")
.setProperty(JMX_MANAGER_PORT, jmxManagerPort + "")
.startServer()
.build();
```
This is the pattern/style recommended for complex rules (it's not my 
invention).



geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
Lines 67 (patched)


Wouldn't it be better to just Chain TemporaryFolder or 
DistributedTemporaryFolder with this Rule? Or maybe pass 
TemporaryFolder.getRoot() into the constructor on this Rule, and then let 
TemporaryFolder handle the before/after for itself. Now we'll have two rules 
that provide temporary directories.



geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
Lines 76 (patched)


I've this behave differently on different operating systems and misbehave 
in general. It creates the illusion to the next developer that this system 
property is mutable, and then it can be nightmare to debug when they use a JDK 
API that theoretically uses "user.dir" but still ends up using the original 
"user.dir" -- I would do everything we can to eliminate usage of "user.dir" or 
back it into a corner (one single line of code in all of Geode).

We can alter any Geode code that relies on relative paths to have absolute 
paths always passed into them. Then this problem goes away. 

Or at the very least it pushes getProperty("user.dir") into a single method 
that finds the root directory for the member. Then you can override this or 
mock it to have it return temporaryFolder.getRoot() instead of 
getProperty("user.dir").
```java
public class WorkingDirectory {

  // override or mock me
  public File getWorkingDirectory() {
return System.getProperty("user.dir");
  }
```
Or:
```java
public class WorkingDirectory {

  private File dir;

  public WorkingDirectory(String path) {
this.dir = new File(path);
  }

  public File getWorkingDirectory() {
return this.dir;
  }
```
Then alter our Geode code to use the above. Immutable system properties and 
static code is a nightmare in tests.


- Kirk Lund


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Upd

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Jinmei Liao]

> On March 2, 2017, 6:31 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
> > Line 140 (original), 114 (patched)
> > 
> >
> > Why is arg changed from 0 to -1? See comment on ServerStartRule

"0" has some confusing meanings. In our product code, sometimes if we set a 
port to 0, it means "use random port". Here I use "-1" to emphasize the fact 
that I don't want this server to connect to any locator, it's a standalone 
server.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167703
---


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
> 7cc1eea2e26b176b570111bccdb8914e19528ecf 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
> 4aa2c69389dce4650cf476f4e8decebddfc36736 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  b5ddee666c52fe39deb015c6e2aa57e5b21e4f20 
> 

[jira] [Commented] (GEODE-2267) Add gfsh command to export stat files

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2267:


Commit a9f0d2272193fdcb43ffaa5b0f06e805ad4effa5 in geode's branch 
refs/heads/develop from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a9f0d22 ]

GEODE-2267: Enhance server/locator startup rules to include workingDir


> Add gfsh command to export stat files
> -
>
> Key: GEODE-2267
> URL: https://issues.apache.org/jira/browse/GEODE-2267
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, gfsh
>Reporter: Diane Hardman
>Assignee: Kirk Lund
>  Labels: ExportClusterArtifacts, export, gfsh, logging, statistics
>
> We would like a single gfsh command to collect and export all logfiles and 
> stat files into a single package that will be returned to the gfsh client 
> machine. This package (zipfile) can then be saved and attached to emails and 
> Jira tickets to help evaluate the Geode cluster status.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Ken Howe]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167703
---




geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
Line 140 (original), 114 (patched)


Why is arg changed from 0 to -1? See comment on ServerStartRule



geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
Line 79 (original), 92 (patched)


Why use locatorPort from 0 to -1? The test in startServer(Properties 
properties, int locatorPort, boolean pdxPersistent) is for >0


- Ken Howe


On March 2, 2017, 3:30 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 3:30 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
> 7cc1eea2e26b176b570111bccdb8914e19528ecf 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
> 4aa2c69389dce4650cf476f4e8decebddfc36736 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  b5ddee666c52fe39deb015c6e2aa57e5b21e4f20 
>   
> geode-web/src/te

[jira] [Assigned] (GEODE-2578) Query string limited to 64 KiB

[Michael Dodge (JIRA)]

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

Michael Dodge reassigned GEODE-2578:


Assignee: Michael Dodge

> Query string limited to 64 KiB
> --
>
> Key: GEODE-2578
> URL: https://issues.apache.org/jira/browse/GEODE-2578
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> The serialization of query strings uses a 16-bit unsigned integer to 
> represent the length of the query string. Query strings with more than 65535 
> characters are silently truncated. Use of a 32-bit unsigned integer to 
> represent the length would greatly increase the size of query strings that 
> may be used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2578) Query string limited to 64 KiB

[Michael Dodge (JIRA)]

Michael Dodge created GEODE-2578:


 Summary: Query string limited to 64 KiB
 Key: GEODE-2578
 URL: https://issues.apache.org/jira/browse/GEODE-2578
 Project: Geode
  Issue Type: Bug
  Components: native client
Reporter: Michael Dodge


The serialization of query strings uses a 16-bit unsigned integer to represent 
the length of the query string. Query strings with more than 65535 characters 
are silently truncated. Use of a 32-bit unsigned integer to represent the 
length would greatly increase the size of query strings that may be used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2571) CacheClosedException during LuceneQueryFunction should be handled with a retry

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2571:


Commit 6d263d57a26226b59ef0bfb1e01205889d3d1409 in geode's branch 
refs/heads/develop from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6d263d5 ]

GEODE-2571 CacheClosedException during LuceneQueryFunction should be handled 
with a retry


> CacheClosedException during LuceneQueryFunction should be handled with a retry
> --
>
> Key: GEODE-2571
> URL: https://issues.apache.org/jira/browse/GEODE-2571
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> There are multiple spots in LuceneQueryFunction that can throw a 
> CacheClosedException.  The query function should handle this and allow the 
> function service to retry instead of returning a CacheClosedException to the 
> user.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] geode pull request #404: Geode 2469

[ggreen]

Github user ggreen commented on a diff in the pull request:

https://github.com/apache/geode/pull/404#discussion_r103993535
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/redis/internal/RegionProvider.java ---
@@ -187,8 +217,26 @@ public boolean removeKey(ByteArrayWrapper key, 
RedisDataType type, boolean cance
   return this.stringsRegion.remove(key) != null;
 } else if (type == RedisDataType.REDIS_HLL) {
   return this.hLLRegion.remove(key) != null;
+} else if (type == RedisDataType.REDIS_LIST) {
+  return this.destroyRegion(key, type);
 } else {
-  return destroyRegion(key, type);
+
+
+  // Check hash
+  ByteArrayWrapper regionName = 
HashInterpreter.toRegionNameByteArray(key);
+  Region region = this.getRegion(regionName);
+  if (region != null) {
+region.remove(HashInterpreter.toEntryKey(key));
--- End diff --

We could return true, but that is what the next line after the if statement 
already returns true
.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (GEODE-2577) merge-log option is ignored for now

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-2577:
---
Summary: merge-log option is ignored for now  (was: merge-log option is 
ignored)

> merge-log option is ignored for now
> ---
>
> Key: GEODE-2577
> URL: https://issues.apache.org/jira/browse/GEODE-2577
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jinmei Liao
>
> We don't merge logs on the server/locator anymore when exporting. We might be 
> able to merge them once they are downloaded to the client machine. Not sure 
> how much value-add this will be.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57242: GEODE-2267: Enhance server/locator startup rules to include workingDir

[Kevin Duling]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57242/#review167696
---


Ship it!




Ship It!

- Kevin Duling


On March 2, 2017, 7:30 a.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57242/
> ---
> 
> (Updated March 2, 2017, 7:30 a.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2267: Enhance server/locator startup rules to include workingDir
> 
> * This batch is mostly test code change, I am enhancing the 
> ServerStartupRules and LocatorStartupRules to have a notion of workingDir 
> itself.
> * There are only 2 product code change: one is the assembly's build.gradle to 
> correctly set the gemfire.home/geode.home, another one is to use an absolute 
> path to check for File's exsistance. Without that, the tests always fail in 
> CI pipeline.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 1c95927f19888b15e771b3cbbc92f120787868c4 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/AgentUtilJUnitTest.java
>  3a29e8a435f5d5362810f5e05ea92a1260e3fbfc 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  f0b6bb327f0424f2e4afa2e057d8e38bd0ef1b39 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  160f6349d94646b12e3114da14e5bff569eed5a9 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  10ce515df8c3630cbf01fc314be454d3e2adfe2c 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  c7d0e7341fcf13bf34a597405d2b42b608004215 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  b5472909eec8d5ca124e7bfd5c6cb71864d9bbee 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 20c948f8f16240aef5c8eae313164693125a99ca 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  05f2c0cb2115ee574666ed3da943c26e8c38c9f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerMBeanShiroJUnitTest.java
>  3183aafd9907ecb15714c2038f2b8c3af31e6e06 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/CacheServerStartupRule.java
>  ea72cfab26f828af9a09f08755a9a7f9ed121654 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  e89bd62b59b8218c30c8f724b4febf2b3ae7721b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsPostProcessorTest.java
>  0980c18de1b504f545355a0f7d650f46c92cc670 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/GfshCommandsSecurityTest.java
>  2d32905d45496fe69e5dc189cd94b82ea163c3b5 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/JavaRmiServerNameTest.java
>  2ae61402d330ab6426c0bc0e0193771ce5dc9c70 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerAuthenticatorDUnitTest.java
>  52afab40990ab3a18fed04fcb001ec9dbe7d045e 
>   
> geode-core/src/test/java/org/apache/geode/security/PeerSecurityWithEmbeddedLocatorDUnitTest.java
>  e87a285d088c923326aa82ee406f543ffc5e0593 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Locator.java 
> fe26e8364798689c1ece487554d99085f3f26f23 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  68447201875ef31a73cfb888d346292e3f084ae8 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorStarterRule.java
>  c3e493e1c176974ed757c71d5c195ff5964dbb57 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Member.java 
> 7cc1eea2e26b176b570111bccdb8914e19528ecf 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/Server.java 
> 4aa2c69389dce4650cf476f4e8decebddfc36736 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
>  b5ddee666c52fe39deb015c6e2aa57e5b21e4f20 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/QueryNamesOverHttpDUnitTest.java
>  1a19e5e5ca90c248655eb40e68aca3c7ed858770 
> 
> 
> Diff: https://reviews.apache.org/r/57242/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: jgroups 4.0.0.Final released

[Bruce Schuchardt]

I think we need to let them shake out problems in the 4.0 code base.  
Bela has already released 4.0.1 due to a critical  bug.


Le 2/27/2017 à 6:58 AM, Dor Ben Dov a écrit :

Hi,

Have it being considered switching from 3.6.10 Final to 4.0.0 Final release.

 From Bella's blog it seems that the new version uses java 8 streams, lambda 
expressions as well as
120 issues that were fixed as well as optimizations.

Regards,
Dor


This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at http://www.amdocs.com/email_disclaimer.asp

[jira] [Created] (GEODE-2577) merge-log option is ignored

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2577:
--

 Summary: merge-log option is ignored
 Key: GEODE-2577
 URL: https://issues.apache.org/jira/browse/GEODE-2577
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


We don't merge logs on the server/locator anymore when exporting. We might be 
able to merge them once they are downloaded to the client machine. Not sure how 
much value-add this will be.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2576) delete the old exported zip on the locator

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2576:
--

 Summary: delete the old exported zip on the locator
 Key: GEODE-2576
 URL: https://issues.apache.org/jira/browse/GEODE-2576
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


Currently when user is exporting logs over jmx connection, a zip file will be 
created in the locator's working dir with a unique file name. If user does 
exports for multiple times, all these zips will be created and we have no 
mechanism to clean them up unless user go in there to delete them.

May need to decide whether this is a problem or not. If it is, we need to 
implement a way to delete these stale zip files periodically.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2575) When user is exporting large amount of data, the http/jmx connection may run into the risk of timing out.

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2575:
--

 Summary: When user is exporting large amount of data, the http/jmx 
connection may run into the risk of timing out.
 Key: GEODE-2575
 URL: https://issues.apache.org/jira/browse/GEODE-2575
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


something should be implemented to keep the connection alive when user is 
exporting large amount of data.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2574) be able to handle other log/stats files suffix or restrict file suffix

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2574:
--

 Summary: be able to handle other log/stats files suffix or 
restrict file suffix
 Key: GEODE-2574
 URL: https://issues.apache.org/jira/browse/GEODE-2574
 Project: Geode
  Issue Type: Sub-task
Reporter: Jinmei Liao


Currently the log exporter only look for .log and .gfs files to export in the 
log and stats file directory. We should either restrict user to specify other 
file suffix or allow them to use whatever suffix they want. 

Also consider .log.gz files for compression.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2425) Refactor tests for export logs

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2425:
--

Assignee: Jinmei Liao

> Refactor tests for export logs
> --
>
> Key: GEODE-2425
> URL: https://issues.apache.org/jira/browse/GEODE-2425
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Right now we have the following tests for export logs:
> {code}
> MiscellaneousCommandsExportLogsPart1DUnitTest
> MiscellaneousCommandsExportLogsPart2DUnitTest
> MiscellaneousCommandsExportLogsPart3DUnitTest
> MiscellaneousCommandsExportLogsPart4DUnitTest
> {code}
> We should endeavor to write unit tests for the rest of sub-tasks in this 
> ticket.  After that is done, it would be prudent to come back to these DUnits 
> and decide which tests are worth keeping, which should be discarded, and 
> whether we need to add any more.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2425) Refactor tests for export logs

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2425.

Resolution: Fixed

> Refactor tests for export logs
> --
>
> Key: GEODE-2425
> URL: https://issues.apache.org/jira/browse/GEODE-2425
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Right now we have the following tests for export logs:
> {code}
> MiscellaneousCommandsExportLogsPart1DUnitTest
> MiscellaneousCommandsExportLogsPart2DUnitTest
> MiscellaneousCommandsExportLogsPart3DUnitTest
> MiscellaneousCommandsExportLogsPart4DUnitTest
> {code}
> We should endeavor to write unit tests for the rest of sub-tasks in this 
> ticket.  After that is done, it would be prudent to come back to these DUnits 
> and decide which tests are worth keeping, which should be discarded, and 
> whether we need to add any more.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2418:
--

Assignee: Jinmei Liao

> Add gfsh post execution handler to detect and download file URLs
> 
>
> Key: GEODE-2418
> URL: https://issues.apache.org/jira/browse/GEODE-2418
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Rather than return the zip file contents in the 'export logs' command result 
> from a locator to a gfsh client, we will return a URL to the exported zip 
> file (GEODE-2417).  We need to write a gfsh post-execution handler (see 
> `org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.ExportInterceptor`)
>  to extract the file URL from the result JSON and download that file via HTTP 
> onto the gfsh client's disk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2417:
--

Assignee: Jinmei Liao

> Generate zip file HTTP URL and manage deletion of zip files
> ---
>
> Key: GEODE-2417
> URL: https://issues.apache.org/jira/browse/GEODE-2417
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Once a locator has built the aggregated zip file described by GEODE-2416, we 
> need that locator to expose an endpoint through the Admin REST api to allow 
> access to that file (perhaps e.g. /exportedArtifact?exportId=foo or 
> /exportedArtifact?name=myLogs.zip).  After the zip file has been successfully 
> downloaded, it should be deleted and the URL invalidated.  Also, the URL 
> should only be valid for some time period (say 24hrs) after which the file 
> will be deleted and URL invalidated even if it is not downloaded, to prevent 
> exported zip files from polluting the locator's disk.  This URL should be 
> returned in the 'export log' command result JSON rather than the file 
> contents.  [Cluster:Read] permissions should be required to access the URL if 
> integrated security is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2417) Generate zip file HTTP URL and manage deletion of zip files

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2417.

Resolution: Fixed

> Generate zip file HTTP URL and manage deletion of zip files
> ---
>
> Key: GEODE-2417
> URL: https://issues.apache.org/jira/browse/GEODE-2417
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Once a locator has built the aggregated zip file described by GEODE-2416, we 
> need that locator to expose an endpoint through the Admin REST api to allow 
> access to that file (perhaps e.g. /exportedArtifact?exportId=foo or 
> /exportedArtifact?name=myLogs.zip).  After the zip file has been successfully 
> downloaded, it should be deleted and the URL invalidated.  Also, the URL 
> should only be valid for some time period (say 24hrs) after which the file 
> will be deleted and URL invalidated even if it is not downloaded, to prevent 
> exported zip files from polluting the locator's disk.  This URL should be 
> returned in the 'export log' command result JSON rather than the file 
> contents.  [Cluster:Read] permissions should be required to access the URL if 
> integrated security is enabled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2418.

Resolution: Fixed

> Add gfsh post execution handler to detect and download file URLs
> 
>
> Key: GEODE-2418
> URL: https://issues.apache.org/jira/browse/GEODE-2418
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> Rather than return the zip file contents in the 'export logs' command result 
> from a locator to a gfsh client, we will return a URL to the exported zip 
> file (GEODE-2417).  We need to write a gfsh post-execution handler (see 
> `org.apache.geode.management.internal.cli.commands.ExportImportClusterConfigurationCommands.ExportInterceptor`)
>  to extract the file URL from the result JSON and download that file via HTTP 
> onto the gfsh client's disk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2419) Outputting proper message telling where the files are exported to.

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2419:
--

Assignee: Jinmei Liao

> Outputting proper message telling where the files are exported to.
> --
>
> Key: GEODE-2419
> URL: https://issues.apache.org/jira/browse/GEODE-2419
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> When user is exporting over jmx connection, we need to tell them that files 
> are exported to the connected member's local file system. If they are 
> connecting over http, then we need to tell them that files are exported to 
> their local system.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2416) Collect together artifacts from individual servers into a single zip file

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2416.

Resolution: Fixed

> Collect together artifacts from individual servers into a single zip file
> -
>
> Key: GEODE-2416
> URL: https://issues.apache.org/jira/browse/GEODE-2416
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need a locator to unzip the individual zip files produced by GEODE-2415 
> and re-zip them together into a single zip file (with a directory for each 
> member, containing the artifacts from that member).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2419) Outputting proper message telling where the files are exported to.

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2419.

Resolution: Fixed

> Outputting proper message telling where the files are exported to.
> --
>
> Key: GEODE-2419
> URL: https://issues.apache.org/jira/browse/GEODE-2419
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jinmei Liao
>
> When user is exporting over jmx connection, we need to tell them that files 
> are exported to the connected member's local file system. If they are 
> connecting over http, then we need to tell them that files are exported to 
> their local system.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2541) NetstatDUnitTest fails with ClassCastException

[Kenneth Howe (JIRA)]

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

Kenneth Howe resolved GEODE-2541.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> NetstatDUnitTest fails with ClassCastException
> --
>
> Key: GEODE-2541
> URL: https://issues.apache.org/jira/browse/GEODE-2541
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
> Fix For: 1.2.0
>
>
> This might be a bug in the error handling code for gfsh or the functions used 
> by MiscellaneousCommands.
> {noformat}
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToJmxManagerOne FAILED
> org.junit.ComparisonFailure: [{"errorCode":505,"message":["Could not 
> process command due to GemFire error. Error occurred while executing netstat 
> on [server-1]"]}] expected:<[OK]> but was:<[ERROR]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:168)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne(NetstatDUnitTest.java:82)
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToJmxManagerTwo FAILED
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.geode.management.internal.cli.result.CommandResult
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeCommand(GfshShellConnectionRule.java:159)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:166)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerTwo(NetstatDUnitTest.java:88)
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToLocator FAILED
> org.junit.ComparisonFailure: [{"errorCode":520,"message":["Could not find 
> member(s) with Id(s) or name(s): server-1."]}] expected:<[OK]> but 
> was:<[ERROR]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:168)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToLocator(NetstatDUnitTest.java:76)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2414.

Resolution: Fixed

> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2415) Write a function to return a zip file for a single server

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2415.

Resolution: Fixed

> Write a function to return a zip file for a single server
> -
>
> Key: GEODE-2415
> URL: https://issues.apache.org/jira/browse/GEODE-2415
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> We need to write a function to be executed on each server that will find the 
> desired artifacts (logs, stat files, stack traces) on that server given the 
> parameters of the export command (date limiting, --exclude-stats, etc) and 
> return that zip file to the calling locator using the mechanism determined by 
> GEODE-2414.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2541) NetstatDUnitTest fails with ClassCastException

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2541:


Commit de0dab309129044c23d122b57d56506add7d847e in geode's branch 
refs/heads/develop from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=de0dab3 ]

GEODE-2541: Fixed ClassCastException failure

Fixed in HeadlessGfsh, and added new test for handling a command response
that's not a CommandResult object


> NetstatDUnitTest fails with ClassCastException
> --
>
> Key: GEODE-2541
> URL: https://issues.apache.org/jira/browse/GEODE-2541
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>  Labels: MiscellaneousCommands, NetstatCommand, gfsh, netstat
>
> This might be a bug in the error handling code for gfsh or the functions used 
> by MiscellaneousCommands.
> {noformat}
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToJmxManagerOne FAILED
> org.junit.ComparisonFailure: [{"errorCode":505,"message":["Could not 
> process command due to GemFire error. Error occurred while executing netstat 
> on [server-1]"]}] expected:<[OK]> but was:<[ERROR]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:168)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerOne(NetstatDUnitTest.java:82)
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToJmxManagerTwo FAILED
> java.lang.ClassCastException: java.lang.String cannot be cast to 
> org.apache.geode.management.internal.cli.result.CommandResult
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeCommand(GfshShellConnectionRule.java:159)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:166)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToJmxManagerTwo(NetstatDUnitTest.java:88)
> org.apache.geode.management.internal.cli.NetstatDUnitTest > 
> testConnectToLocator FAILED
> org.junit.ComparisonFailure: [{"errorCode":520,"message":["Could not find 
> member(s) with Id(s) or name(s): server-1."]}] expected:<[OK]> but 
> was:<[ERROR]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.dunit.rules.GfshShellConnectionRule.executeAndVerifyCommand(GfshShellConnectionRule.java:168)
> at 
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testConnectToLocator(NetstatDUnitTest.java:76)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2419) Outputting proper message telling where the files are exported to.

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-2419:
---
Description: When user is exporting over jmx connection, we need to tell 
them that files are exported to the connected member's local file system. If 
they are connecting over http, then we need to tell them that files are 
exported to their local system.  (was: Our strategy for the revised `export 
logs` command relies on the locator running the Admin REST API, which is 
enabled by default but can be optionally disabled.  We need to add a good error 
message for the `export logs` command if Admin REST is disabled on the locator.)

> Outputting proper message telling where the files are exported to.
> --
>
> Key: GEODE-2419
> URL: https://issues.apache.org/jira/browse/GEODE-2419
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> When user is exporting over jmx connection, we need to tell them that files 
> are exported to the connected member's local file system. If they are 
> connecting over http, then we need to tell them that files are exported to 
> their local system.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2419) Outputting proper message telling where the files are exported to.

[Jinmei Liao (JIRA)]

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

Jinmei Liao updated GEODE-2419:
---
Summary: Outputting proper message telling where the files are exported to. 
 (was: Add error message for export logs if Admin REST is disabled)

> Outputting proper message telling where the files are exported to.
> --
>
> Key: GEODE-2419
> URL: https://issues.apache.org/jira/browse/GEODE-2419
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our strategy for the revised `export logs` command relies on the locator 
> running the Admin REST API, which is enabled by default but can be optionally 
> disabled.  We need to add a good error message for the `export logs` command 
> if Admin REST is disabled on the locator.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Build failed in Jenkins: Geode-nightly #764

[Apache Jenkins Server]

See 


Changes:

[abaker] GEODE-2551 Fix code issues found by AppChecker

[dbarnes] GEODE-2561 Docs: error in gfsecurity.properties example (Geode User

[kmiller] GEODE-2562 CTR  Revise docs Main Features section

[kmiller] GEODE-2562 CTR  Revise docs Main Features section

[kmiller] GEODE-2562 Revise Main Features paragraph per review

[kmiller] Revert "GEODE-2562 Revise Main Features paragraph per review"

--
[...truncated 100.41 KB...]
java.lang.OutOfMemoryError: Java heap space

org.apache.geode.management.internal.cli.NetstatDUnitTest > 
testConnectToLocator FAILED
java.lang.OutOfMemoryError: Java heap space

309 tests completed, 3 failed, 8 skipped
:geode-core:flakyTest FAILED
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJava
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.6.RELEASE/spring-test-4.3.6.RELEASE.pom
Download https://repo1.maven.org/maven2/com/tdunning/json/1.8/json-1.8.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.6.RELEASE/spring-test-4.3.6.RELEASE.jar
Download https://repo1.maven.org/maven2/com/tdunning/json/1.8/json-1.8.jar
Note: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pu

Updated dependency versions

[Kirk Lund]

I finished updating versions of most of our 3rd party dependencies *[1]*
except for the following:

*1) antlr*
2.7.7 (Jan, 2007) <-- current version
4.6 (Dec, 2016)

Upgrading antlr will probably require changing a lot more than imports. I'm
going to leave this to someone more familiar with the querying code.

*2) jetty*
9.3.6.v20151106 (Nov, 2015) <-- current version
9.4.0.v20161208 (Dec, 2016)
9.4.2.v20170220 (Feb, 2017)

I tried upgrading to 9.4.0.v20161208 and RestSecurityIntegrationTest
failed. I filed "GEODE-2539: Upgrading Jetty causes
RestSecurityIntegrationTest to fail" and I hope to resume working on this
soon.

*3) jgroups*
3.6.10.Final (Jun, 2016) <-- current version
3.6.13.Final (Feb, 2017)
4.0.0.Final (Feb, 2017)

This dependency is used for our distributed system membership. I'm going to
leave this to someone more familiar with Geode's use of JGroups.

*4) jna*
4.0.0 (Jul, 2013) <-- current version
4.3.0 (Jan, 2017)

Upgrading jna to 4.3.0 results in compilation errors in
geode-core/src/main/java/org/apache/geode/internal/shared/NativeCallsJNAImpl.java
which doesn't appear to have any tests. I filed "GEODE-2557: Upgrade jna
dependency" and put this on hold until we have time to write some unit
tests for this class.

*5) mockito*
1.10.19 (Dec, 2014) <-- current version
2.7.11 (Feb, 2017)
2.7.12 (Feb, 2017)

This upgrade results in lots of compilation errors. After changing the
broken APIs to the new versions, there are many tests using mockito that
fail. The failures are not straight forward. This blog article *[2]* does a
good job explaining what I'm seeing when I attempt this upgrade.

I filed "GEODE-2558: Upgrade mockito dependency" -- this is going to take
quite a bit of work. The tests span all of the Geode components, and it
would be ideal if we could have several committers and/or contributors work
together on a feature branch to fix the failures. I'll follow-up on this in
the near future.

[1] https://issues.apache.org/jira/browse/GEODE-2460
[2] https://asolntsev.github.io/en/2016/10/11/mockito-2.1/