[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:

Description: 
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*

Attached [^gemfire-oql-orderby-vs-on-client-sort-test-cases.zip] can demo the 
problem (check the comments below).
Attached are also the JMC profiler [^flight_recording_OQL_ORDER_BY.jfr], logs 
and vsd stats

The profiler suggests that most  of the CPU goes to the 
*OrderByComparator#evaluateSortCriteria* method:
!oql_with_order_by_hot_methods.png!



  was:
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*


> 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*
> Attached [^gemfire-oql-orderby-vs-on-client-sort-test-cases.zip] can demo the 
> problem (check the comments below).
> Attached are also the JMC profiler [^flight_recording_OQL_ORDER_BY.jfr], logs 
> and vsd stats
> The profiler suggests that most  of the CPU goes to the 
> *OrderByComparator#evaluateSortCriteria* method:
> !oql_with_order_by_hot_methods.png!



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

[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=15893786#comment-15893786
 ] 

Christian Tzolov edited comment on GEODE-2588 at 3/3/17 2:48 PM:
-

Demo project [^gemfire-oql-orderby-vs-on-client-sort-test-cases.zip]  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}


was (Author: tzolov):
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: 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*
> Attached [^gemfire-oql-orderby-vs-on-client-sort-test-cases.zip] can demo the 
> problem (check the comments below).
> Attached are also the JMC profiler [^flight_recording_OQL_ORDER_BY.jfr], logs 
> and vsd stats
> The profiler suggests that most  of the CPU goes to the 
> *OrderByComparator#evaluateSortCriteria* method:
> !oql_with_order_by_hot_methods.png!



--
This message was sent by Atlassian JIRA
(v6.3

Build failed in Jenkins: Geode-nightly #765

[Apache Jenkins Server]

See 


Changes:

[nag] GEODE-2572: getCache method implemented for LuceneService

[klund] GEODE-4160: upgrade mortbay-jetty-servlet-api dependency

[khowe] GEODE-2541: Fixed ClassCastException failure

[huynhja] GEODE-2571 CacheClosedException during LuceneQueryFunction should be

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

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

[khowe] GEODE-2488: Remove lsof from netstat command tests

[upthewaterspout] Overhauling the javadocs for the LuceneService

--
[...truncated 101.04 KB...]
at 
org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)

Caused by:
org.apache.geode.SystemConnectException: Unable to find a free port in 
the membership-port-range
at 
org.apache.geode.internal.net.SocketCreator.createServerSocketUsingPortRange(SocketCreator.java:847)
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:671)
... 12 more

6818 tests completed, 1 failed, 603 skipped
:geode-core:distributedTest FAILED
:geode-core:flakyTest
: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:compileTestJavaNote: 

 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-pul

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 3, 2017, 4:17 p.m.)


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


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/management/internal/cli/CliAroundInterceptor.java
 11d74c13311923357e82318b32bf0342e156e0c6 
  
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/ConfigCommands.java
 12a0a64202ed56fb48e970066b9e8838b9d6bef3 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 bd6772803b2f109b9ca0fc98e059c8a86464d85c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
 e94af4f3f34e6fc43c86b23a942e30ac28d58505 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
 91810e88ee19f938fd0c13116a4736e671d4df6a 
  
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/remote/RemoteExecutionStrategy.java
 4b827a9e9022d06553ee2441ed50acd72252fb77 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
 ac912c82c873c443dd268f07e8874b5bd18fdd0b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptorJUnitTest.java
 c938f0755142209150a5a91a3764c54b009bb3a3 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/57243/diff/3/

Changes: https://reviews.apache.org/r/57243/diff/2-3/


Testing
---

precheckin running (hopefully last one)


Thanks,

Jinmei Liao

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

[Jinmei Liao]

> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > 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.

there are dunit tests around it. Will add more tests.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > 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.

I extracted the command to its own class, but left the implementation intact 
for now. We have test and integration tests that tests around LogExporter. Will 
file a JIRA ticket to make the exportlogcommand more testable.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > 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.

the region is destroyed by the receiver of the function (because it's a 
replicated region, once the region is destroyed on the server, it will be 
destroyed on the locator). 

We are doing this because if we leave the regions around, then then the put 
messages will be broadcasted to all the members. We had to choose between the 
network overhead or region create/destroy overhead. We chose the latter.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > 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.

It does use a LogExporter.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > 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?

Yes, the LogExportCommand uses it to craete the region on the locator.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
> > Lines 142 (patched)
> > 
> >
> > Does this need to be public?

yes, the command uses it.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
> > Lines 159 (patched)
> > 
> >
> > Can this be made private?

the command will need to create the argument.


> On March 2, 2017, 7:24 p.m., Kirk Lund wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
> > Lines 208 (patched)
> > 
> >
> > Can this be made private?

command uese it.


- Jinmei


---

Unable to allocate a failure detection port in the membership-port range

[Kirk Lund]

Geode nightly build failed because it couldn't find a free port "in the
membership-port range"

Bruce, Is this a particularly small range? If not then maybe we should
consider blacklisting this build machine.

org.apache.geode.GemFireConfigException: Unable to allocate a failure
detection port in the membership-port range
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
at
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
at
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
at
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
at
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
at
org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)
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.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: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.GeneratedMethodAccessor6.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.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.GeneratedMethodAccessor5.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.

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

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On March 2, 2017, 7:12 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57249/
> ---
> 
> (Updated March 2, 2017, 7:12 p.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
> 
>

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

[Jinmei Liao]

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




geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
Lines 94 (patched)


Maybe add the JIRA ticket number in the ignore message @Ignore("GEODE-xxx").


- Jinmei Liao


On March 2, 2017, 7:12 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57249/
> ---
> 
> (Updated March 2, 2017, 7:12 p.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
> 
>

Re: Unable to allocate a failure detection port in the membership-port range

[Bruce Schuchardt]

In this case the test is restricting the port range to three ports. It 
looks like a flaky test to me because it's finding a free port and is 
assuming that two adjacent ports are also free.


Le 3/3/2017 à 9:03 AM, Kirk Lund a écrit :
Geode nightly build failed because it couldn't find a free port "in 
the membership-port range"


Bruce, Is this a particularly small range? If not then maybe we should 
consider blacklisting this build machine.


org.apache.geode.GemFireConfigException: Unable to allocate a failure 
detection port in the membership-port range
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
at 
org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)

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.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: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.GeneratedMethodAccessor6.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.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.GeneratedMethodAccessor5.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflec

[GitHub] geode-native pull request #45: GEODE-2513 Unbrand statistics section of geod...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-2513 Unbrand statistics section of geode-native manual

@joeymcallister @davebarnes97 @dgkimura @PivotalSarge @echobravopapa 
@mmartell Please review this PR.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-3

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

https://github.com/apache/geode-native/pull/45.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 #45


commit 6768a9e01e8065f800e562eb06253df01464b027
Author: Karen Miller 
Date:   2017-03-03T18:00:36Z

GEODE-2513 Unbrand statistics section of geode-native manual




---
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-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2513 Unbrand statistics section of geode-native manual

@joeymcallister @davebarnes97 @dgkimura @PivotalSarge @echobravopapa 
@mmartell Please review this PR.

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

$ git pull https://github.com/karensmolermiller/geode-native 
feature/GEODE-2513-3

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

https://github.com/apache/geode-native/pull/45.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 #45


commit 6768a9e01e8065f800e562eb06253df01464b027
Author: Karen Miller 
Date:   2017-03-03T18:00:36Z

GEODE-2513 Unbrand statistics section of geode-native manual




> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[jira] [Commented] (GEODE-2560) Missing disk files (.crf) during backup/restore throws exception

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2560:


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

GEODE-2560: Missing disk files (.crf) during backup/restore throws exception


> Missing disk files (.crf) during backup/restore throws exception
> 
>
> Key: GEODE-2560
> URL: https://issues.apache.org/jira/browse/GEODE-2560
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> The old FileUtil.copy was a noop if the src file did not exist.
> The new FileUtils.copyFile throws a FileNotFoundException if the src file 
> does not exist.
> Protect against missing file.



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

Travis CI on github

[Nabarun Nag]

Hi All,

Travis CI at the github page
https://github.com/apache/geode/commits/develop seems
to be stuck at yellow status for all our commits since 2nd March 2017.
Looking at the page https://travis-ci.org/apache/geode/jobs/207079576 we
see the message "Hang tight, the log cannot be shown until the build has
started" . The commit was done 24hrs ago.

Can someone with credentials / privileges look into it or point me on how
to fix this issue.

Regards
Nabarun Nag

[jira] [Created] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2589:
--

 Summary: lucene index region is not inheriting recoveryDelay and 
startupRecoveryDelay from data region
 Key: GEODE-2589
 URL: https://issues.apache.org/jira/browse/GEODE-2589
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey
 Fix For: 1.2.0


The lucene index region uses the default values for recoveryDelay and 
startupRecoveryDelay vs. the values configured for the data region.

It should inherit these values from the PartitionRegionAttributes of the data 
region.





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

[jira] [Created] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[Shelley Lynn Hughes-Godfrey (JIRA)]

Shelley Lynn Hughes-Godfrey created GEODE-2590:
--

 Summary: The lucene index region should not set the diskStoreName 
for non-persistent regions
 Key: GEODE-2590
 URL: https://issues.apache.org/jira/browse/GEODE-2590
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Shelley Lynn Hughes-Godfrey


The lucene index region is always configuring the diskStoreName even when the 
data region is not persistent.  It should only configure this RegionAttribute 
when the configured dataPolicy has persistence.



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

[jira] [Updated] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2589:
---
Fix Version/s: (was: 1.2.0)

> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[jira] [Assigned] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey reassigned GEODE-2589:
--

Assignee: Shelley Lynn Hughes-Godfrey

> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[jira] [Assigned] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey reassigned GEODE-2590:
--

Assignee: Shelley Lynn Hughes-Godfrey

> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

[jira] [Updated] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey updated GEODE-2589:
---
Affects Version/s: 1.2.0

> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

Re: Also Requesting more JIRA permission

[Dan Smith]

You now have contributor permissions on the geode jira. Welcome! Here's a
couple of links that might be useful: JIRA guidlines
 and How
to Contribute
.

Thanks!
-Dan


On Thu, Mar 2, 2017 at 4:30 PM, Diane Rose Hardman 
wrote:

> 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
> > >
> >
>

Re: Travis CI on github

[Anthony Baker]

I’ve noticed things have been slowing down recently.  I believe ASF has a 
limited size travis-ci execution pool for all projects.  You can ask for help 
on the INFRA hipchat channel:  https://www.hipchat.com/gIjVtYcNy

Anthony

> On Mar 3, 2017, at 11:12 AM, Nabarun Nag  wrote:
> 
> Hi All,
> 
> Travis CI at the github page
> https://github.com/apache/geode/commits/develop seems
> to be stuck at yellow status for all our commits since 2nd March 2017.
> Looking at the page https://travis-ci.org/apache/geode/jobs/207079576 we
> see the message "Hang tight, the log cannot be shown until the build has
> started" . The commit was done 24hrs ago.
> 
> Can someone with credentials / privileges look into it or point me on how
> to fix this issue.
> 
> Regards
> Nabarun Nag

[jira] [Commented] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2590:


Commit 24d02a5862851ceffa715233f245c46651776cf4 in geode's branch 
refs/heads/feature/GEODE-2589 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=24d02a5 ]

GEODE-2589, GEODE-2590 lucene index region attributes should be based on data 
region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay from 
data region
- lucene index region now only sets diskStoreName (in RegionAttributes) when 
data region has persistence.


> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

[jira] [Commented] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2589:


Commit 24d02a5862851ceffa715233f245c46651776cf4 in geode's branch 
refs/heads/feature/GEODE-2589 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=24d02a5 ]

GEODE-2589, GEODE-2590 lucene index region attributes should be based on data 
region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay from 
data region
- lucene index region now only sets diskStoreName (in RegionAttributes) when 
data region has persistence.


> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[GitHub] geode pull request #411: GEODE-2589, GEODE-2590 lucene index region attribut...

[ladyVader]

GitHub user ladyVader opened a pull request:

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

GEODE-2589, GEODE-2590 lucene index region attributes should be based…

lucene index region attributes should reflect those on data region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay 
from data region
- lucene index region now only sets diskStoreName (in RegionAttributes) 
when data region has persistence.

@upthewaterspout @nabarunnag  - Could you please review these changes?

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

$ git pull https://github.com/apache/geode feature/GEODE-2589

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

https://github.com/apache/geode/pull/411.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 #411


commit 24d02a5862851ceffa715233f245c46651776cf4
Author: Lynn Hughes-Godfrey 
Date:   2017-03-03T21:11:53Z

GEODE-2589, GEODE-2590 lucene index region attributes should be based on 
data region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay 
from data region
- lucene index region now only sets diskStoreName (in RegionAttributes) 
when data region has persistence.




---
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-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[ASF GitHub Bot (JIRA)]

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

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

GitHub user ladyVader opened a pull request:

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

GEODE-2589, GEODE-2590 lucene index region attributes should be based…

lucene index region attributes should reflect those on data region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay 
from data region
- lucene index region now only sets diskStoreName (in RegionAttributes) 
when data region has persistence.

@upthewaterspout @nabarunnag  - Could you please review these changes?

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

$ git pull https://github.com/apache/geode feature/GEODE-2589

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

https://github.com/apache/geode/pull/411.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 #411


commit 24d02a5862851ceffa715233f245c46651776cf4
Author: Lynn Hughes-Godfrey 
Date:   2017-03-03T21:11:53Z

GEODE-2589, GEODE-2590 lucene index region attributes should be based on 
data region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay 
from data region
- lucene index region now only sets diskStoreName (in RegionAttributes) 
when data region has persistence.




> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[jira] [Assigned] (GEODE-11) Lucene Integration

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-11:


Assignee: Dave Barnes  (was: xiaojian zhou)

> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: Dave Barnes
>  Labels: experimental
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Created] (GEODE-2591) User guide: Lucene headings should be reflected in navigation pane

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2591:
--

 Summary: User guide: Lucene headings should be reflected in 
navigation pane
 Key: GEODE-2591
 URL: https://issues.apache.org/jira/browse/GEODE-2591
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Dave Barnes


The left-hand subnav for the Lucene section of the user guide does not match 
the topics in the text.



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

[jira] [Updated] (GEODE-11) Lucene Integration

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-11:
-
Priority: Minor  (was: Major)

> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: Dave Barnes
>Priority: Minor
>  Labels: experimental
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Assigned] (GEODE-11) Lucene Integration

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-11:


Assignee: xiaojian zhou  (was: Dave Barnes)

> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>Priority: Minor
>  Labels: experimental
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Updated] (GEODE-11) Lucene Integration

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-11:
-
Priority: Major  (was: Minor)

> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>  Labels: experimental
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Assigned] (GEODE-2591) User guide: Lucene headings should be reflected in navigation pane

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2591:
--

Assignee: Dave Barnes

> User guide: Lucene headings should be reflected in navigation pane
> --
>
> Key: GEODE-2591
> URL: https://issues.apache.org/jira/browse/GEODE-2591
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> The left-hand subnav for the Lucene section of the user guide does not match 
> the topics in the text.



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

[jira] [Updated] (GEODE-2591) User guide: Lucene headings should be reflected in navigation pane

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-2591:
---
Priority: Minor  (was: Major)

> User guide: Lucene headings should be reflected in navigation pane
> --
>
> Key: GEODE-2591
> URL: https://issues.apache.org/jira/browse/GEODE-2591
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> The left-hand subnav for the Lucene section of the user guide does not match 
> the topics in the text.



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

[GitHub] geode-native pull request #45: GEODE-2513 Unbrand statistics section of geod...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


Commit 6768a9e01e8065f800e562eb06253df01464b027 in geode-native's branch 
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=6768a9e ]

GEODE-2513 Unbrand statistics section of geode-native manual


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1793:


Commit 866dc5ca1583c5fab49ec96c48d261c0367427f3 in geode's branch 
refs/heads/feature/GEODE-1793 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=866dc5c ]

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.


> 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-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2542:


Commit 866dc5ca1583c5fab49ec96c48d261c0367427f3 in geode's branch 
refs/heads/feature/GEODE-1793 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=866dc5c ]

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.


> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode 
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Kirk Lund
>  Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
> asf919.gq1.ygridcore.net with 5 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
>   at 
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
>   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.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: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.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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$Dispatc

Re: 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/
---

(Updated March 3, 2017, 9:55 p.m.)


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


Repository: geode


Description (updated)
---

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.

This is a minor update to incorporate suggestions from review.
After discussion with klund, moving the test class out of the FlakyTest 
category.


Diffs (updated)
-

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


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

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


Testing
---

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


Thanks,

Ken Howe

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

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On March 3, 2017, 9:55 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57249/
> ---
> 
> (Updated March 3, 2017, 9:55 p.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.
> 
> This is a minor update to incorporate suggestions from review.
> After discussion with klund, moving the test class out of the FlakyTest 
> category.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
>  e987fc2 
> 
> 
> Diff: https://reviews.apache.org/r/57249/diff/2/
> 
> 
> Testing
> ---
> 
> Tested locally on JVMs with small heap to verify there are no OOMEs
> Precheckin has been started.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

[jira] [Commented] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2590:


Commit 4e61799f918d47340ddb0ecbcf89aaf715723d95 in geode's branch 
refs/heads/feature/GEODE-2589 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4e61799 ]

GEODE-2590 Fix unit tests related to creating lucene index and chunk regions


> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

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

[ASF GitHub Bot (JIRA)]

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

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

GitHub user bschuchardt opened a pull request:

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

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOther…

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the 
superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.

I deleted one of the tests in LocatorDUnitTest as it wasn't doing any 
useful validation and really served no purpose.

I also increased the joinTimeout in this test.  The original 1-second 
timeout was intended to make the tests run faster but I think it's probably the 
source of some of the flaky-ness in this set of tests.  Some of them were also 
overriding the joinTimeout established by the DUnit framework, so that was 
actually a bad thing to be doing.  The tests all run in a few seconds with the 
default joinTimeout setting anyway.


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

$ git pull https://github.com/apache/geode feature/GEODE-1793

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

https://github.com/apache/geode/pull/412.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 #412


commit 866dc5ca1583c5fab49ec96c48d261c0367427f3
Author: Bruce Schuchardt 
Date:   2017-03-03T21:47:42Z

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the 
superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.




> 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 #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[bschuchardt]

GitHub user bschuchardt opened a pull request:

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

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOther…

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the 
superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.

I deleted one of the tests in LocatorDUnitTest as it wasn't doing any 
useful validation and really served no purpose.

I also increased the joinTimeout in this test.  The original 1-second 
timeout was intended to make the tests run faster but I think it's probably the 
source of some of the flaky-ness in this set of tests.  Some of them were also 
overriding the joinTimeout established by the DUnit framework, so that was 
actually a bad thing to be doing.  The tests all run in a few seconds with the 
default joinTimeout setting anyway.


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

$ git pull https://github.com/apache/geode feature/GEODE-1793

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

https://github.com/apache/geode/pull/412.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 #412


commit 866dc5ca1583c5fab49ec96c48d261c0367427f3
Author: Bruce Schuchardt 
Date:   2017-03-03T21:47:42Z

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the 
superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.




---
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-2444) Making Redis Adapter easier to use and more robust

[Addison (JIRA)]

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

Addison updated GEODE-2444:
---
Issue Type: Wish  (was: New Feature)

> Making Redis Adapter easier to use and more robust
> --
>
> Key: GEODE-2444
> URL: https://issues.apache.org/jira/browse/GEODE-2444
> Project: Geode
>  Issue Type: Wish
>  Components: redis
>Reporter: Addison
>
> The goal of this effort is to further test and complete the Redis Adapter to 
> make the code more readable and performant. 



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

[GitHub] geode issue #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSL...

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/412
  
There are "spotless" problems I'm cleaning up, and I'm removing the 
commented out code from the test.


---
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

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/412
  
There are "spotless" problems I'm cleaning up, and I'm removing the 
commented out code from the test.


> 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)

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 3, 2017, 10:17 p.m.)


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


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
-

  
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/CommandRequest.java
 b0242c9e8ee656001cf76155f4e727ece07666a2 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
 12a0a64202ed56fb48e970066b9e8838b9d6bef3 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 bd6772803b2f109b9ca0fc98e059c8a86464d85c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
 e94af4f3f34e6fc43c86b23a942e30ac28d58505 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
 91810e88ee19f938fd0c13116a4736e671d4df6a 
  
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/remote/RemoteExecutionStrategy.java
 4b827a9e9022d06553ee2441ed50acd72252fb77 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
 ac912c82c873c443dd268f07e8874b5bd18fdd0b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptorJUnitTest.java
 c938f0755142209150a5a91a3764c54b009bb3a3 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
 PRE-CREATION 


Diff: https://reviews.apache.org/r/57243/diff/3/


Testing (updated)
---

precheckin Successful with the latest changes


Thanks,

Jinmei Liao

[GitHub] geode pull request #413: GEODE-2591 User guide: Lucene headings should be re...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2591 User guide: Lucene headings should be reflected in navigat…

…ion pane

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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2591

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

https://github.com/apache/geode/pull/413.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 #413


commit 15587b22c92c3df85d0c9249eac56f42fc0bf931
Author: Dave Barnes 
Date:   2017-03-03T22:19:35Z

GEODE-2591 User guide: Lucene headings should be reflected in navigation 
pane




---
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-2591) User guide: Lucene headings should be reflected in navigation pane

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2591 User guide: Lucene headings should be reflected in navigat…

…ion pane

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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-2591

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

https://github.com/apache/geode/pull/413.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 #413


commit 15587b22c92c3df85d0c9249eac56f42fc0bf931
Author: Dave Barnes 
Date:   2017-03-03T22:19:35Z

GEODE-2591 User guide: Lucene headings should be reflected in navigation 
pane




> User guide: Lucene headings should be reflected in navigation pane
> --
>
> Key: GEODE-2591
> URL: https://issues.apache.org/jira/browse/GEODE-2591
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> The left-hand subnav for the Lucene section of the user guide does not match 
> the topics in the text.



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

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #489 was SUCCESSFUL (with 1680 tests)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #489 was successful.
---
Scheduled
1682 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode pull request #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[galen-pivotal]

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

https://github.com/apache/geode/pull/412#discussion_r104258182
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -360,6 +360,13 @@ private void processRequest(final Socket sock) {
   versionOrdinal = (short) 
GOSSIP_TO_GEMFIRE_VERSION_MAP.get(gossipVersion);
 } else {
   // Close the socket. We can not accept requests from a newer 
version
+  try {
+sock.getOutputStream().write("unknown protocol 
version".getBytes());
--- End diff --

Is there any risk of this being interpreted by anything other than garbage 
on the other side?


---
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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/412#discussion_r104258182
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -360,6 +360,13 @@ private void processRequest(final Socket sock) {
   versionOrdinal = (short) 
GOSSIP_TO_GEMFIRE_VERSION_MAP.get(gossipVersion);
 } else {
   // Close the socket. We can not accept requests from a newer 
version
+  try {
+sock.getOutputStream().write("unknown protocol 
version".getBytes());
--- End diff --

Is there any risk of this being interpreted by anything other than garbage 
on the other side?


> 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 #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[galen-pivotal]

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

https://github.com/apache/geode/pull/412#discussion_r104258974
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -77,9 +77,9 @@
* 
* This should be incremented if the gossip message structures change
* 
-   * 1000 - gemfire 5.5 - using java serialization 1001 - 5.7 - using 
DataSerializable and
--- End diff --

Did spotless break this? 😮 


---
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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/412#discussion_r104258974
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -77,9 +77,9 @@
* 
* This should be incremented if the gossip message structures change
* 
-   * 1000 - gemfire 5.5 - using java serialization 1001 - 5.7 - using 
DataSerializable and
--- End diff --

Did spotless break this? 😮 


> 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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/412#discussion_r104259153
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -77,9 +77,9 @@
* 
* This should be incremented if the gossip message structures change
* 
-   * 1000 - gemfire 5.5 - using java serialization 1001 - 5.7 - using 
DataSerializable and
--- End diff --

I didn't check but that's my assumption.  It likes the comment with the 
HTML breaks in place.


> 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 #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[bschuchardt]

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

https://github.com/apache/geode/pull/412#discussion_r104259153
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -77,9 +77,9 @@
* 
* This should be incremented if the gossip message structures change
* 
-   * 1000 - gemfire 5.5 - using java serialization 1001 - 5.7 - using 
DataSerializable and
--- End diff --

I didn't check but that's my assumption.  It likes the comment with the 
HTML breaks in place.


---
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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/412#discussion_r104260160
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -360,6 +360,13 @@ private void processRequest(final Socket sock) {
   versionOrdinal = (short) 
GOSSIP_TO_GEMFIRE_VERSION_MAP.get(gossipVersion);
 } else {
   // Close the socket. We can not accept requests from a newer 
version
+  try {
+sock.getOutputStream().write("unknown protocol 
version".getBytes());
--- End diff --

This situation should never happen.  When we fetch the protocol version of 
a Locator we use v5.7.  Then we use the locator's protocol version in future 
communications.  We will never send a higher version number than the locator 
knows how to handle.

For SSL, this text is nothing like the response to a HelloClient packet.  
On machines I've tested on it results in either a SSLHandshakeException or a 
SSLException hinting that the other end might be using plain text sockets.


> 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 #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[bschuchardt]

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

https://github.com/apache/geode/pull/412#discussion_r104260160
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
 ---
@@ -360,6 +360,13 @@ private void processRequest(final Socket sock) {
   versionOrdinal = (short) 
GOSSIP_TO_GEMFIRE_VERSION_MAP.get(gossipVersion);
 } else {
   // Close the socket. We can not accept requests from a newer 
version
+  try {
+sock.getOutputStream().write("unknown protocol 
version".getBytes());
--- End diff --

This situation should never happen.  When we fetch the protocol version of 
a Locator we use v5.7.  Then we use the locator's protocol version in future 
communications.  We will never send a higher version number than the locator 
knows how to handle.

For SSL, this text is nothing like the response to a HelloClient packet.  
On machines I've tested on it results in either a SSLHandshakeException or a 
SSLException hinting that the other end might be using plain text sockets.


---
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] [Created] (GEODE-2592) Document Lucene-related gfsh commands

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-2592:
--

 Summary: Document Lucene-related gfsh commands
 Key: GEODE-2592
 URL: https://issues.apache.org/jira/browse/GEODE-2592
 Project: Geode
  Issue Type: New Feature
  Components: docs
Reporter: Dave Barnes


Add four new Lucene-related gfsh commands to the gfsh command reference pages:
create lucene index, describe lucene index, list lucene indexes, search lucene.



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

[jira] [Commented] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2590:


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

GEODE-2590 Fix unit tests related to creating lucene index and chunk regions


> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

[jira] [Assigned] (GEODE-2592) Document Lucene-related gfsh commands

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-2592:
--

Assignee: Dave Barnes

> Document Lucene-related gfsh commands
> -
>
> Key: GEODE-2592
> URL: https://issues.apache.org/jira/browse/GEODE-2592
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Add four new Lucene-related gfsh commands to the gfsh command reference pages:
> create lucene index, describe lucene index, list lucene indexes, search 
> lucene.



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

[jira] [Commented] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[GitHub] geode pull request #411: GEODE-2589, GEODE-2590 lucene index region attribut...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2589:


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

GEODE-2589, GEODE-2590 lucene index region attributes should be based on data 
region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay from 
data region
- lucene index region now only sets diskStoreName (in RegionAttributes) when 
data region has persistence.


> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[jira] [Commented] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2590:


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

GEODE-2589, GEODE-2590 lucene index region attributes should be based on data 
region

- lucene index region now inherits recoveryDelay and startupRecoveryDelay from 
data region
- lucene index region now only sets diskStoreName (in RegionAttributes) when 
data region has persistence.


> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

[jira] [Commented] (GEODE-2568) When its AsyncEventQueue is destroyed, its JMX MBean is not removed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2568:


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

GEODE-2568: The JMX MBean is now removed when its AsyncEventQueue is removed


> When its AsyncEventQueue is destroyed, its JMX MBean is not removed
> ---
>
> Key: GEODE-2568
> URL: https://issues.apache.org/jira/browse/GEODE-2568
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> This results in the exception below if the AsyncEventQueue is re-added:
> {noformat}
> [warning 2017/03/01 10:53:33.500 PST   0> tid=0x3f] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:114)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:407)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleAsyncEventQueueCreation(ManagementAdapter.java:584)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:186)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.addAsyncEventQueue(GemFireCacheImpl.java:4068)
>   at 
> org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueFactoryImpl.create(AsyncEventQueueFactoryImpl.java:197)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.createAEQ(LuceneIndexImpl.java:184)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.createAEQ(LuceneIndexImpl.java:150)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.initialize(LuceneIndexImpl.java:140)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.afterDataRegionCreated(LuceneServiceImpl.java:227)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl$1.afterCreate(LuceneServiceImpl.java:207)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionAfter(GemFireCacheImpl.java:3370)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3349)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3190)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3178)
>   at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
>   at CreateRegionFunction.createRegion(CreateRegionFunction.java:27)
>   at CreateRegionFunction.execute(CreateRegionFunction.java:22)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction66.executeFunctionaLocally(ExecuteFunction66.java:324)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction66.cmdExecute(ExecuteFunction66.java:249)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction70.cmdExecute(ExecuteFunction70.java:55)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
>   at com.s

[jira] [Resolved] (GEODE-2568) When its AsyncEventQueue is destroyed, its JMX MBean is not removed

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2568.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> When its AsyncEventQueue is destroyed, its JMX MBean is not removed
> ---
>
> Key: GEODE-2568
> URL: https://issues.apache.org/jira/browse/GEODE-2568
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
>
> This results in the exception below if the AsyncEventQueue is re-added:
> {noformat}
> [warning 2017/03/01 10:53:33.500 PST   0> tid=0x3f] javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
> org.apache.geode.management.ManagementException: 
> javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
>   at 
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:114)
>   at 
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:407)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleAsyncEventQueueCreation(ManagementAdapter.java:584)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:186)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2146)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:536)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.addAsyncEventQueue(GemFireCacheImpl.java:4068)
>   at 
> org.apache.geode.cache.asyncqueue.internal.AsyncEventQueueFactoryImpl.create(AsyncEventQueueFactoryImpl.java:197)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.createAEQ(LuceneIndexImpl.java:184)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.createAEQ(LuceneIndexImpl.java:150)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneIndexImpl.initialize(LuceneIndexImpl.java:140)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.afterDataRegionCreated(LuceneServiceImpl.java:227)
>   at 
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl$1.afterCreate(LuceneServiceImpl.java:207)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.invokeRegionAfter(GemFireCacheImpl.java:3370)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3349)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3190)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3178)
>   at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
>   at CreateRegionFunction.createRegion(CreateRegionFunction.java:27)
>   at CreateRegionFunction.execute(CreateRegionFunction.java:22)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction66.executeFunctionaLocally(ExecuteFunction66.java:324)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction66.cmdExecute(ExecuteFunction66.java:249)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteFunction70.cmdExecute(ExecuteFunction70.java:55)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException: 
> GemFire:service=AsyncEventQueue,queue=cusip_index#_data,type=Member,member=192.168.2.9(74354)-1026
>   at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.regi

[jira] [Resolved] (GEODE-2589) lucene index region is not inheriting recoveryDelay and startupRecoveryDelay from data region

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey resolved GEODE-2589.

   Resolution: Fixed
Fix Version/s: 1.2.0

> lucene index region is not inheriting recoveryDelay and startupRecoveryDelay 
> from data region
> -
>
> Key: GEODE-2589
> URL: https://issues.apache.org/jira/browse/GEODE-2589
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> The lucene index region uses the default values for recoveryDelay and 
> startupRecoveryDelay vs. the values configured for the data region.
> It should inherit these values from the PartitionRegionAttributes of the data 
> region.



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

[jira] [Resolved] (GEODE-2590) The lucene index region should not set the diskStoreName for non-persistent regions

[Shelley Lynn Hughes-Godfrey (JIRA)]

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

Shelley Lynn Hughes-Godfrey resolved GEODE-2590.

   Resolution: Fixed
Fix Version/s: 1.2.0

> The lucene index region should not set the diskStoreName for non-persistent 
> regions
> ---
>
> Key: GEODE-2590
> URL: https://issues.apache.org/jira/browse/GEODE-2590
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> The lucene index region is always configuring the diskStoreName even when the 
> data region is not persistent.  It should only configure this RegionAttribute 
> when the configured dataPolicy has persistence.



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

[jira] [Created] (GEODE-2593) DistributedSystemDUnitTest.testUDPPortRange fails intermittently with SystemConnectException: Unable to find a free port in the membership-port-range

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2593:


 Summary: DistributedSystemDUnitTest.testUDPPortRange fails 
intermittently with SystemConnectException: Unable to find a free port in the 
membership-port-range
 Key: GEODE-2593
 URL: https://issues.apache.org/jira/browse/GEODE-2593
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Kirk Lund


{noformat}
org.apache.geode.GemFireConfigException: Unable to allocate a failure detection 
port in the membership-port range
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
at 
org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)
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.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: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.GeneratedMethodAccessor6.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvoca

[jira] [Updated] (GEODE-2593) DistributedSystemDUnitTest.testUDPPortRange fails intermittently with SystemConnectException: Unable to find a free port in the membership-port-range

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2593:
-
Description: 
DistributedSystemDUnitTest.testUDPPortRange fails intermittently because it 
finds a free port and then assume that two adjacent ports are also free.
{noformat}
org.apache.geode.GemFireConfigException: Unable to allocate a failure detection 
port in the membership-port range
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
at 
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
at 
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
at 
org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
at 
org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
at 
org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
at 
org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
at 
org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
at 
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
at 
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
at 
org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)
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.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: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.GeneratedMethodAccessor6.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unk

[jira] [Updated] (GEODE-2593) DistributedSystemDUnitTest.testUDPPortRange fails intermittently with SystemConnectException: Unable to find a free port in the membership-port-range

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2593:
-
Labels: Flaky  (was: )

> DistributedSystemDUnitTest.testUDPPortRange fails intermittently with 
> SystemConnectException: Unable to find a free port in the 
> membership-port-range
> -
>
> Key: GEODE-2593
> URL: https://issues.apache.org/jira/browse/GEODE-2593
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>  Labels: Flaky
>
> DistributedSystemDUnitTest.testUDPPortRange fails intermittently because it 
> finds a free port and then assume that two adjacent ports are also free.
> {noformat}
> org.apache.geode.GemFireConfigException: Unable to allocate a failure 
> detection port in the membership-port range
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.createServerSocket(GMSHealthMonitor.java:675)
>   at 
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.started(GMSHealthMonitor.java:941)
>   at 
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:171)
>   at 
> org.apache.geode.distributed.internal.membership.gms.GMSMemberFactory.newMembershipManager(GMSMemberFactory.java:102)
>   at 
> org.apache.geode.distributed.internal.membership.MemberFactory.newMembershipManager(MemberFactory.java:89)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1112)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.(DistributionManager.java:1160)
>   at 
> org.apache.geode.distributed.internal.DistributionManager.create(DistributionManager.java:531)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:687)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:299)
>   at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:206)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:197)
>   at 
> org.apache.geode.distributed.DistributedSystemDUnitTest.testUDPPortRange(DistributedSystemDUnitTest.java:307)
>   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.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: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.GeneratedMethodAccessor6.invoke(Unknown Source)
>  

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

[Ken Howe]

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


Ship it!




LGTM. I reviewed the diffs from the original to the latest (version 3) without 
examining the intermediate changes.

As these changes appear that they won't break nightly builds (your precheckin 
passed), it would be great to get this merged so that further refinements to 
the export logs command behavior can be dealt with individually.

- Ken Howe


On March 3, 2017, 10:17 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57243/
> ---
> 
> (Updated March 3, 2017, 10:17 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> 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
> -
> 
>   
> 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/CommandRequest.java
>  b0242c9e8ee656001cf76155f4e727ece07666a2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  12a0a64202ed56fb48e970066b9e8838b9d6bef3 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  bd6772803b2f109b9ca0fc98e059c8a86464d85c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  e94af4f3f34e6fc43c86b23a942e30ac28d58505 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  91810e88ee19f938fd0c13116a4736e671d4df6a 
>   
> 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/remote/RemoteExecutionStrategy.java
>  4b827a9e9022d06553ee2441ed50acd72252fb77 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
>  ac912c82c873c443dd268f07e8874b5bd18fdd0b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptorJUnitTest.java
>  c938f0755142209150a5a91a3764c54b009bb3a3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57243/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin Successful with the latest changes
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On March 3, 2017, 2:17 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57243/
> ---
> 
> (Updated March 3, 2017, 2:17 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> 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
> -
> 
>   
> 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/CommandRequest.java
>  b0242c9e8ee656001cf76155f4e727ece07666a2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  12a0a64202ed56fb48e970066b9e8838b9d6bef3 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  bd6772803b2f109b9ca0fc98e059c8a86464d85c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  e94af4f3f34e6fc43c86b23a942e30ac28d58505 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  91810e88ee19f938fd0c13116a4736e671d4df6a 
>   
> 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/remote/RemoteExecutionStrategy.java
>  4b827a9e9022d06553ee2441ed50acd72252fb77 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
>  ac912c82c873c443dd268f07e8874b5bd18fdd0b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptorJUnitTest.java
>  c938f0755142209150a5a91a3764c54b009bb3a3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57243/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin Successful with the latest changes
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2415:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - 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


> 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-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=15895286#comment-15895286
 ] 

ASF subversion and git services commented on GEODE-2267:


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

GEODE-2267: enable gfsh to download file from http connection (GEODE-2418)


> 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)

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2414:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - 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


> 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] [Commented] (GEODE-2416) Collect together artifacts from individual servers into a single zip file

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2416:


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

GEODE-2416: Collect together artifacts from individual servers into a single 
zip file

 - 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


> 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] [Commented] (GEODE-2418) Add gfsh post execution handler to detect and download file URLs

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2418:


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

GEODE-2267: enable gfsh to download file from http connection (GEODE-2418)


> 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] [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=15895288#comment-15895288
 ] 

ASF subversion and git services commented on GEODE-2267:


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

GEODE-2267:  add validation to the arguments and include export stats in the 
command

  * use the config to determine where the logs and stats are


> 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 57249: GEODE-2488: Remove lsof from netstat command tests

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On March 3, 2017, 9:55 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57249/
> ---
> 
> (Updated March 3, 2017, 9:55 p.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.
> 
> This is a minor update to incorporate suggestions from review.
> After discussion with klund, moving the test class out of the FlakyTest 
> category.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java
>  e987fc2 
> 
> 
> Diff: https://reviews.apache.org/r/57249/diff/2/
> 
> 
> Testing
> ---
> 
> Tested locally on JVMs with small heap to verify there are no OOMEs
> Precheckin has been started.
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

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

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On March 3, 2017, 10:17 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57243/
> ---
> 
> (Updated March 3, 2017, 10:17 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> 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
> -
> 
>   
> 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/CommandRequest.java
>  b0242c9e8ee656001cf76155f4e727ece07666a2 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  12a0a64202ed56fb48e970066b9e8838b9d6bef3 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  bd6772803b2f109b9ca0fc98e059c8a86464d85c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  e94af4f3f34e6fc43c86b23a942e30ac28d58505 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  91810e88ee19f938fd0c13116a4736e671d4df6a 
>   
> 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/remote/RemoteExecutionStrategy.java
>  4b827a9e9022d06553ee2441ed50acd72252fb77 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/MiscellaneousCommandsController.java
>  ac912c82c873c443dd268f07e8874b5bd18fdd0b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/AbstractCliAroundInterceptorJUnitTest.java
>  c938f0755142209150a5a91a3764c54b009bb3a3 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsInterceptorJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57243/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin Successful with the latest changes
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Review Request 57311: GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange

[Kirk Lund]

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

Review request for geode, Anthony Baker, Bruce Schuchardt, Jinmei Liao, Jared 
Stewart, Ken Howe, and Mark Bretl.


Bugs: GEODE-2593
https://issues.apache.org/jira/browse/GEODE-2593


Repository: geode


Description
---

GEODE-2593: add port range to AvailablePortHelper to fix testUDPPortRange


Diffs
-

  
geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
 c57ad1760a9de45b10a0298d601d57c4fce97633 
  geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelper.java 
e09a7a06a46adbae56eadce5f63039d7bbeb886d 
  
geode-core/src/test/java/org/apache/geode/internal/AvailablePortHelperIntegrationTest.java
 PRE-CREATION 


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


Testing
---

AvailablePortHelperIntegrationTest
DistributedSystemDUnitTest
precheckin in progress


Thanks,

Kirk Lund