[jira] [Commented] (GEODE-2763) Remove of nonSingleHopsCount stat in client

[ASF GitHub Bot (JIRA)]

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

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

Github user ameybarve15 commented on the issue:

https://github.com/apache/geode-native/pull/90
  
Hi @echobravopapa , and @PivotalSarge Thanks for your review.
I am trying to merge my pull request but get this error.

>~/source/open/t/geode-native (develop) $ git fetch ameyGitHub 
pull/90/head:feature/GEODE-2763
fatal: Couldn't find remote ref pull/90/head

Please help me resolve the issue.



> Remove of nonSingleHopsCount stat in client
> ---
>
> Key: GEODE-2763
> URL: https://issues.apache.org/jira/browse/GEODE-2763
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Michael Dodge
>Assignee: Amey Barve
>
> A pre-existing issue (GEODE-2017) required the removal of the 
> nonSingleHopsCount statistic in the clients. Whilst marked for the native 
> client as well, it was not addressed in the native client. It should be.



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

[GitHub] geode-native issue #90: GEODE-2763: Remove of nonSingleHopsCount stat in cli...

[ameybarve15]

Github user ameybarve15 commented on the issue:

https://github.com/apache/geode-native/pull/90
  
Hi @echobravopapa , and @PivotalSarge Thanks for your review.
I am trying to merge my pull request but get this error.

>~/source/open/t/geode-native (develop) $ git fetch ameyGitHub 
pull/90/head:feature/GEODE-2763
fatal: Couldn't find remote ref pull/90/head

Please help me resolve the issue.



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

Review Request 58599: GEODE:2802 Tombstone version vector to contain only the members that generate the tombstone.

[anilkumar gingade]

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

Review request for geode, Darrel Schneider, Eric Shu, and Lynn Gallinat.


Repository: geode


Description
---

TombstoneMessage serialization code assumes the member info in RVV to be either 
membership-id or disk-id and uses this info while de-serializing.
When there is a mix of persistent and non-persistent region in the cluster 
(between nodes), the above assumption will not hold good; resulting in data 
serialization exception.

When there is a mix of persistent and non-persistent region, the version info 
is always generated from the persistent member. While constructing the 
tombstone message, even though there is no tombstone version generated on 
non-persistent member, it was added into the tombstone message, resulting in 
mixed version source, causing deserialization failure.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/versions/RegionVersionVector.java
 2e01c00 
  
geode-core/src/test/java/org/apache/geode/internal/cache/versions/TombstoneDUnitTest.java
 PRE-CREATION 


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


Testing
---

Manual testing.
Added new dunit test. Verified the failure without change.
precheckin in progress.


Thanks,

anilkumar gingade

Re: Review Request 58594: even lost primary, dispatched batch should still be removed

[Barry Oglesby]

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


Ship it!




This looks ok. The only places that call 
ParallelGatewaySenderQueue.destroyEventFromQueue are the AckReaderThread after 
a successfully processed batch and the ConflationHandler to conflate an entry.

The ConflationHandler only is called by BRQ virtualPut if 
this.getBucketAdvisor().isPrimary(), so removing that call should be ok.

Have you run conflation tests to verify?

- Barry Oglesby


On April 20, 2017, 9:08 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58594/
> ---
> 
> (Updated April 20, 2017, 9:08 p.m.)
> 
> 
> Review request for geode and Jason Huynh.
> 
> 
> Bugs: GEODE-2806
> https://issues.apache.org/jira/browse/GEODE-2806
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> one of the known root causes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
>  cf4c5a9ef 
> 
> 
> Diff: https://reviews.apache.org/r/58594/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

[jira] [Commented] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2681:


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

GEODE-2681: WIP: DUnit test for show missing-disk-stores


> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Kenneth Howe
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

Re: Review Request 58594: even lost primary, dispatched batch should still be removed

[Jason Huynh]

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


Ship it!




Maybe also have someone else review (maybe Barry) because I kind of supplied 
this same fix...looks good to me but it would be good to get another set of 
eyes on it.

- Jason Huynh


On April 20, 2017, 9:08 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58594/
> ---
> 
> (Updated April 20, 2017, 9:08 p.m.)
> 
> 
> Review request for geode and Jason Huynh.
> 
> 
> Bugs: GEODE-2806
> https://issues.apache.org/jira/browse/GEODE-2806
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> one of the known root causes
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
>  cf4c5a9ef 
> 
> 
> Diff: https://reviews.apache.org/r/58594/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #530 was successful.
---
Scheduled
1845 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 58595: GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance

[Ken Howe]

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

(Updated April 20, 2017, 10:41 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Changes
---

Changed test to use InternalCache interface


Repository: geode


Description
---

This is a first pass review of the fix of gfsh hang on "show  
missing-disk-stores" command when cache is initializing (i.e. waiting for a 
missing disk-store). I'm working on a new DUnit test validate this change, and 
will update the review when it's ready.

GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance

In the JUnit test, renamed some variables to make things a more readable. Also 
removed try/catches around unexpected Exceptions to let the testing framework 
handle them.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunction.java
 a2812faa1f0310fd7e1861fe5c3623cb9ba79f97 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ShowMissingDiskStoresFunctionJUnitTest.java
 1cfa24270c3e4b6a59156c70d3ba478307af234a 


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

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


Testing
---

Verified manually using the steps noted in GEODE-2798 (which is a dupilcate of 
GEODE-2681.)

Precheckin has been started.


Thanks,

Ken Howe

[jira] [Commented] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2681:


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

GEODE-2681: Fix JUnit test - use InternalCache


> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Kenneth Howe
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

[jira] [Resolved] (GEODE-1274) Pulse logging does not appear in Geode log file.

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-1274.
-
Resolution: Fixed

> Pulse logging does not appear in Geode log file.
> 
>
> Key: GEODE-1274
> URL: https://issues.apache.org/jira/browse/GEODE-1274
> Project: Geode
>  Issue Type: Bug
>  Components: logging, pulse
>Affects Versions: 1.0.0-incubating, 1.1.0
>Reporter: Jens Deppe
>  Labels: Log4j2
>
> While trying to enable debug logging for Pulse, I found that no Pulse logging 
> appears in the Geode log. The Admin REST logging does appear though.
> I had tried to enable debug logging by starting a locator with the followiing 
> log4j config:
> {noformat}
> 
>  packages="com.gemstone.gemfire.internal.logging.log4j">
>   
> [%level{lowerCase=true} %date{/MM/dd 
> HH:mm:ss.SSS z} %thread tid=%tid] %message%n%throwable%n
>   
>   
> 
>   
> 
>   
>   
> 
> 
>onMismatch="NEUTRAL"/>
> 
> 
> 
> 
>   
> 
>   
> 
> {noformat}
> However, only the Admin REST app produced debug log output. 



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

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit 2d842cda8767f7fbc9db9cc197a87e2bf354a42b in geode's branch 
refs/heads/feature/GEODE-2681 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2d842cd ]

GEODE-728: Using the correct parameter in withArgs

ServerRegionFunctionExecutor.withArgs was not using it's argument, it
was just passing the (null) field named args to setArguments.


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

[jira] [Commented] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2103:


Commit a43a9e5cc166c027934495bd401a5738959d125e in geode's branch 
refs/heads/feature/GEODE-2681 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a43a9e5 ]

GEODE-2103 Revise http-service-port defn per review


> start locator command should include --http-service-port and 
> --http-service-bind-address
> 
>
> Key: GEODE-2103
> URL: https://issues.apache.org/jira/browse/GEODE-2103
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> To facilitate starting the Admin REST API on a Locator, start locator command 
> should include --http-service-port and --http-service-bind-address.
> Workaround is to specify these configuration properties with --J:
> --J=-Dgemfire.http-service-port=
> --J=-Dgemfire.http-service-bind-address=



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

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit 3261319c6eccdc25b0d5b42ae56b30d634590e9a in geode's branch 
refs/heads/feature/GEODE-2681 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3261319 ]

GEODE-728: Rename Execution.withArgs to Execution.setArguments

 * created setArguments
 * deprecated withArgs
 * implemented setArguments of all Execution implementations in Geode project
 * replaced all of withArgs with setArguments

This closes #457


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

[jira] [Commented] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2681:


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

GEODE-2681: refactoring to prevent synchronization hang on getAnyInstance

Take advantage of recent refactoring to use the InternalCache interface API
instead of GemFireCahceImpl.


> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Kenneth Howe
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

[jira] [Commented] (GEODE-510) Bug48571DUnitTest.testStatsMatchWithSize failed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-510:
---

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

GEODE-510 Bug48571DUnitTest.testStatsMatchWithSize failed

This ticket was marked fixed in early 2016 but the Flaky annotation was
never removed and it was reopened by Anthony with no comment.  I'm removing
the Flaky annotation and closing the ticket.


> Bug48571DUnitTest.testStatsMatchWithSize failed
> ---
>
> Key: GEODE-510
> URL: https://issues.apache.org/jira/browse/GEODE-510
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: xiaojian zhou
>  Labels: CI, Flaky
> Fix For: 1.0.0-incubating.M3, 1.2.0
>
>
> revision d08e51d2eaa391fcda11cd18ee4413aa5fe6b80d
> {noformat}
> dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.ha.Bug48571DUnitTest.createClientCache in 
> VM 1 running on Host venezuela.gemstone.com with 4 VMs
>   at dunit.VM.invoke(VM.java:170)
>   at 
> com.gemstone.gemfire.internal.cache.ha.Bug48571DUnitTest.testStatsMatchWithSize(Bug48571DUnitTest.java:99)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Could not 
> initialize a 

[jira] [Commented] (GEODE-2796) NPE in ClassPathLoader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2796:


Commit b842c708fa5b38a374201f4592e253fb4c7a46b8 in geode's branch 
refs/heads/feature/GEODE-2681 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b842c70 ]

GEODE-2796: ClassPathLoader does not blow up with null TCCL


> NPE in ClassPathLoader
> --
>
> Key: GEODE-2796
> URL: https://issues.apache.org/jira/browse/GEODE-2796
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> It looks like an NPE was introduced by the fix for GEODE-2290:
> {noformat}
> Caused by: java.lang.NullPointerException
> at 
> org.apache.geode.internal.ClassPathLoader.getResource(ClassPathLoader.java:130)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:239)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:264)
> at 
> org.apache.geode.internal.GemFireVersion$VersionDescription.(GemFireVersion.java:191)
> at 
> org.apache.geode.internal.GemFireVersion.getDescription(GemFireVersion.java:52)
> at 
> org.apache.geode.internal.GemFireVersion.getGemFireVersion(GemFireVersion.java:66)
> at org.apache.geode.cache.CacheFactory.getVersion(CacheFactory.java:305)
> ...
> {noformat}
> This is caused by the following method: 
> {noformat}
>  private List getClassLoaders() {
> ArrayList classLoaders = new ArrayList<>();
> if (!excludeTCCL) {
>   classLoaders.add(Thread.currentThread().getContextClassLoader());
> }
> classLoaders.add(classLoaderForDeployedJars);
> return classLoaders;
>   }
> {noformat}
> According to the JavaDocs, `getContextClassLoader()` actually returns null to 
> indicate the system class loader (rather than actually returning the system 
> class loader).



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

[jira] [Commented] (GEODE-2103) start locator command should include --http-service-port and --http-service-bind-address

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2103:


Commit e94f825159c8c341c50f9c8ffacca506c64845ea in geode's branch 
refs/heads/feature/GEODE-2681 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=e94f825 ]

GEODE-2103 Update gfsh start server|locator command
reference page.

- the optional http-service-port defaults to 7070
- both http-service-port and http-service-bind-address
are available for gfsh start server and gfsh start locator


> start locator command should include --http-service-port and 
> --http-service-bind-address
> 
>
> Key: GEODE-2103
> URL: https://issues.apache.org/jira/browse/GEODE-2103
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> To facilitate starting the Admin REST API on a Locator, start locator command 
> should include --http-service-port and --http-service-bind-address.
> Workaround is to specify these configuration properties with --J:
> --J=-Dgemfire.http-service-port=
> --J=-Dgemfire.http-service-bind-address=



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


Commit 52fad33b6a40c7a947baa08d8c509f5104710f7d in geode's branch 
refs/heads/feature/GEODE-2681 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=52fad33 ]

GEODE-2632: refactor code to use interfaces instead of impls

* use getInternalDistributedSystem instead of overriding getDistributedSystem
* use InternalCache instead of GemFireCacheImpl
* remove dead code
* remove useless javadocs and comments


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Commented] (GEODE-2653) GMSJoinLeaveJUnitTest.testRemoveMember fails with AssertionError

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2653:


Commit b163a8eb75f0834c09dbc770b443851f739c0ee8 in geode's branch 
refs/heads/feature/GEODE-2681 from [~gosullivan]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=b163a8e ]

GEODE-2653: Fix testRemoveMember and remove FlakyTest. This closes #437

Test removed self instead of the other member, and used the `any`
matcher instead of `isA`.

Cleanup GMSJoinLeaveJUnitTest.

* Change Mockito's `any` to `isA`.
* Replace some `Thread.sleep()` calls with Awaitility calls.
* Remove our `MethodExecuted` class -- this can be done with Mockito's
  `verify()`.

Remove a redundant assert.


> GMSJoinLeaveJUnitTest.testRemoveMember fails with AssertionError
> 
>
> Key: GEODE-2653
> URL: https://issues.apache.org/jira/browse/GEODE-2653
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Galen O'Sullivan
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Intermittent failure stack:
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest
>  > testRemoveMember FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testRemoveMember(GMSJoinLeaveJUnitTest.java:337)
> {noformat}
> This test looks like it's flaky due to the Thread sleep:
> {noformat}
>   @Test
>   public void testRemoveMember() throws Exception {
> initMocks();
> prepareAndInstallView(mockMembers[0], createMemberList(mockMembers[0], 
> gmsJoinLeaveMemberId));
> MethodExecuted removeMessageSent = new MethodExecuted();
> 
> when(messenger.send(any(RemoveMemberMessage.class))).thenAnswer(removeMessageSent);
> gmsJoinLeave.remove(mockMembers[0], "removing for test");
> Thread.sleep(ServiceConfig.MEMBER_REQUEST_COLLECTION_INTERVAL * 2);
> assertTrue(removeMessageSent.methodExecuted);
>   }
> {noformat}



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

[jira] [Commented] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2605:


Commit f6d3ab7f89e9d373075c3df28060c9c23a96aaa2 in geode's branch 
refs/heads/feature/GEODE-2681 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f6d3ab7 ]

GEODE-2605: Modified gfsh search lucene to require DATA:WRITE privilege to 
match client


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
>Assignee: Barry Oglesby
> Fix For: 1.2.0
>
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

Re: Review Request 58541: GEODE-576 & GEODE-516 Flaky test: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[Udo Kohlmeyer]

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


Ship it!




Ship It!

- Udo Kohlmeyer


On April 19, 2017, 8:27 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58541/
> ---
> 
> (Updated April 19, 2017, 8:27 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, Udo Kohlmeyer, 
> and Dan Smith.
> 
> 
> Bugs: GEODE-516 and GEODE-576
> https://issues.apache.org/jira/browse/GEODE-516
> https://issues.apache.org/jira/browse/GEODE-576
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Replaced pauses with Awaitility.  Modified asyncs to use the DUnit blackboard 
> to synchronize their actions for repeatable behavior.  Cleaned up static 
> locks to allow their reuse in other tests or in repeating the same test.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  e0bbde06ba2ce8e8db55627920ee6cf23e4badb2 
> 
> 
> Diff: https://reviews.apache.org/r/58541/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Refactor gfsh parser

[Jared Stewart]

+1 for the suggested aliases

> On Apr 20, 2017, at 3:02 PM, Jinmei Liao  wrote:
> 
> We should add option alias to to those options like "member(s)",
> "group(s)", "jar(s)", so that the command will accept either singular or
> plural. SpringShell parser does allow us to add option aliases.
> 
> On Thu, Apr 20, 2017 at 2:40 PM, Bruce Schuchardt 
> wrote:
> 
>> +1
>> What other options like "member" exist that need to be modified?
>> 
>> 
>> Le 4/20/2017 à 1:37 PM, Jinmei Liao a écrit :
>> 
>>> In the effort of adding option validation to gfsh commands (GEODE-1597)
>>> and
>>> simplifying gfsh parsing, I started this exercise of only using
>>> SpringShell's parser instead of a combination of springshell's,
>>> joptsimple's and our own parsers. The end result is a lot more manageable
>>> code base,  and the capability to validate the option list, but does have
>>> these following different behaviors, and I would like the community's
>>> wight
>>> in on whether or not these are acceptable or not:
>>> 
>>> 1) SpringShell doesn't allow you to specify an option twice, so for
>>> multivalued parameters, our old parser can accept command like
>>> 
>>> "change loglevel --member=member1 --member=member2",
>>> 
>>> but now the parser will give you an error, and you should only do
>>> "change loglevel --member=member1,member2".
>>> 
>>> The new parser did something speical for --J option though, so for --J,
>>> you
>>> can specify it multiple times.
>>> 2) For value separator, springShell default's to ",", you can only
>>> overwrite it with option context "splittingRegex", we do not honor the
>>> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
>>> separators, so this won't break our commands, but if there is any command
>>> out there that would define a different @CliMetaData(valueSepartor=) other
>>> than ",", SpringShell would not know how to parse it.
>>> 3) To specify empty string as parameter value, before you will need to do
>>> 
>>> put region=A key="''" value="''"
>>> 
>>> spring shell would think the value you are trying to pass in are two
>>> single
>>> quotes instead of empty strings, now, you should only do
>>> 
>>> put region=A key="" value=""
>>> 
>>> Cheers
>>> 
>>> Jinmei
>>> 
>>> 
>> 
> 
> 
> -- 
> Cheers
> 
> Jinmei

[jira] [Commented] (GEODE-1228) ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt commented on GEODE-1228:
-

I'll modify this test to use the locator to find servers and let the servers do 
a wild-card bind.  That will avoid any use of AvailablePortHelper.

> ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover
> -
>
> Key: GEODE-1228
> URL: https://issues.apache.org/jira/browse/GEODE-1228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: xiaojian zhou
>Assignee: Bruce Schuchardt
>  Labels: CI, Flaky
> Fix For: 1.0.0-incubating.M3
>
>
> {noformat}
> Geode_develop_DistributedTests/2260
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.security.ClientAuthzObjectModDUnitTest$$Lambda$517/1376300375.call
>  in VM 0 running on Host japan.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:346)
>   at 
> com.gemstone.gemfire.security.ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover(ClientAuthzObjectModDUnitTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> 

Re: Refactor gfsh parser

[Jinmei Liao]

We should add option alias to to those options like "member(s)",
"group(s)", "jar(s)", so that the command will accept either singular or
plural. SpringShell parser does allow us to add option aliases.

On Thu, Apr 20, 2017 at 2:40 PM, Bruce Schuchardt 
wrote:

> +1
> What other options like "member" exist that need to be modified?
>
>
> Le 4/20/2017 à 1:37 PM, Jinmei Liao a écrit :
>
>> In the effort of adding option validation to gfsh commands (GEODE-1597)
>> and
>> simplifying gfsh parsing, I started this exercise of only using
>> SpringShell's parser instead of a combination of springshell's,
>> joptsimple's and our own parsers. The end result is a lot more manageable
>> code base,  and the capability to validate the option list, but does have
>> these following different behaviors, and I would like the community's
>> wight
>> in on whether or not these are acceptable or not:
>>
>> 1) SpringShell doesn't allow you to specify an option twice, so for
>> multivalued parameters, our old parser can accept command like
>>
>> "change loglevel --member=member1 --member=member2",
>>
>> but now the parser will give you an error, and you should only do
>> "change loglevel --member=member1,member2".
>>
>> The new parser did something speical for --J option though, so for --J,
>> you
>> can specify it multiple times.
>> 2) For value separator, springShell default's to ",", you can only
>> overwrite it with option context "splittingRegex", we do not honor the
>> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
>> separators, so this won't break our commands, but if there is any command
>> out there that would define a different @CliMetaData(valueSepartor=) other
>> than ",", SpringShell would not know how to parse it.
>> 3) To specify empty string as parameter value, before you will need to do
>>
>> put region=A key="''" value="''"
>>
>> spring shell would think the value you are trying to pass in are two
>> single
>> quotes instead of empty strings, now, you should only do
>>
>> put region=A key="" value=""
>>
>> Cheers
>>
>> Jinmei
>>
>>
>


-- 
Cheers

Jinmei

[jira] [Assigned] (GEODE-1228) ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt reassigned GEODE-1228:
---

Assignee: Bruce Schuchardt  (was: Udo Kohlmeyer)

> ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover
> -
>
> Key: GEODE-1228
> URL: https://issues.apache.org/jira/browse/GEODE-1228
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: xiaojian zhou
>Assignee: Bruce Schuchardt
>  Labels: CI, Flaky
> Fix For: 1.0.0-incubating.M3
>
>
> {noformat}
> Geode_develop_DistributedTests/2260
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.security.ClientAuthzObjectModDUnitTest$$Lambda$517/1376300375.call
>  in VM 0 running on Host japan.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:346)
>   at 
> com.gemstone.gemfire.security.ClientAuthzObjectModDUnitTest.testAllOpsObjectModWithFailover(ClientAuthzObjectModDUnitTest.java:117)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> 

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

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

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

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/450
  
Regarding putting JMH benchmarks in the core - seems fine. I think I 
originally made geode-benchmarks a separate project so it would be easy to 
share code and compare benchmarks between modules - eg comparing lucene to OQL 
queries. But putting the benchmarks in each module maybe makes more sense.

This does seem to be somewhat stretching what JMH is designed for. JMH is 
targeted towards *microbenchmarks* so launching a separate server process seems 
a bit of a stretch. In particular, it's not clear to me here whether your 
server is getting restarted between benchmark iterations. JMH specifically 
tries to restart the JVM multiple times to deal with inconsistencies, but maybe 
only your client is getting restarted? In general I think we should probably be 
focusing on single VM, smaller unit benchmarks with JMH - benchmarking 
distributed systems might be better done with a different framework and 
multiple hosts.


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

[upthewaterspout]

Github user upthewaterspout commented on the issue:

https://github.com/apache/geode/pull/450
  
Regarding putting JMH benchmarks in the core - seems fine. I think I 
originally made geode-benchmarks a separate project so it would be easy to 
share code and compare benchmarks between modules - eg comparing lucene to OQL 
queries. But putting the benchmarks in each module maybe makes more sense.

This does seem to be somewhat stretching what JMH is designed for. JMH is 
targeted towards *microbenchmarks* so launching a separate server process seems 
a bit of a stretch. In particular, it's not clear to me here whether your 
server is getting restarted between benchmark iterations. JMH specifically 
tries to restart the JVM multiple times to deal with inconsistencies, but maybe 
only your client is getting restarted? In general I think we should probably be 
focusing on single VM, smaller unit benchmarks with JMH - benchmarking 
distributed systems might be better done with a different framework and 
multiple hosts.


---
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] [Closed] (GEODE-2290) Provide way to limit scanning of deployed jars

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar closed GEODE-2290.
---

> Provide way to limit scanning of deployed jars
> --
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>  Labels: ClassLoader, DeployCommand, deploy, gfsh
> Fix For: 1.2.0
>
>
> Currently if you use the GFSH command "deploy jar" the deployed jar will be 
> scanned in such a way that the deployer will load and resolve every .class 
> file in the jar file. The original intention of "deploy jar" was that only 
> Functions would be deployed. Any .class that is found to be a Function is 
> automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as 
> CacheListener. If you then follow up the deploy with "alter region" you can 
> alter the region to add the CacheListener or other callback.
> Some users have reported trying to deploy a jar with much more than just 
> Functions or CacheListeners or domain classes used for Region Entries. If the 
> jar includes a class that the callbacks or domain classes don't directly use 
> but that class requires a missing transitive dependency, then the deployer 
> will generate a NoClassDefFoundError when it tries to load and resolve that 
> class.
> Along with the potential NoClassDefFoundError, forcing every .class to be 
> loaded and resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar 
> without having the deployer generate NoClassDefFoundError. This requires 
> something like one of the following approaches:
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load 
> and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on 
> dev@geode.apache.org]



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

Re: Review Request 58582: GEODE-2632: 1st pass cleaning up GemFireCacheImpl

[Kirk Lund]

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

(Updated April 20, 2017, 9:49 p.m.)


Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, and Ken 
Howe.


Changes
---

-1 somehow my changes broke BucketRegionQueue


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


Repository: geode


Description
---

GEODE-2632: 1st pass cleaning up GemFireCacheImpl

* remove dead-code
* add @Override annotations
* remove uselss javadocs and comments
* reduce scope of constants/vars/methods where possible
* fix misc IDE warnings
* remove unused imports (and reorg imports)

This turned out to be a big diff so I'm submitting a separate review just for 
this cleanup.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyCache.java 
76306f51fc9479c7d9acaa28022ed908b674b7c0 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
709308b57da847845ef9319bece18ebe9f25e569 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 a5f0fc2bc7cf4250565aa8dd139004890b8da07d 
  
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
 d6a1efa73028e1b9514db67d2e3a4b564abee632 
  geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
54d9e503f2645d045487cea51011143602764f62 
  geode-core/src/test/java/org/apache/geode/TXWriterTestCase.java 
987f22f688ca695a8b37eacf239c69c329bb3b3b 
  geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterJUnitTest.java 
0a61b1f258d090090321c9ccff1a25781da7c8d1 
  
geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterOOMEJUnitTest.java 
b99d3fd25cdac5f1862927d098d9d6381894510e 
  geode-core/src/test/java/org/apache/geode/internal/cache/PRTXJUnitTest.java 
d2bad641a47f68edb22da0f89a04c462ab48cd33 


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


Testing (updated)
---

precheckin fails

These changes seem to cause failures elsewhere (BucketRegionQueue) in a way 
that I can't seem to figure out. I think I'll have to scrap this change set and 
start over with GemFireCacheImpl, running this test every few changes. This 
collection seems to be at the root of the problem:

  private final BlockingQueue eventSeqNumQueue = new 
LinkedBlockingQueue();

The class declares it as  but then casts it elsewhere to  and 
then iterates over it and finds Long instead of EventID. The code on develop 
does indeed put both EventID and Long in that Queue, but on my branch it seems 
to leave a Long in the Queue which the code then blows up on during the 
iterating.

java.lang.ClassCastException: java.lang.Long cannot be cast to 
org.apache.geode.internal.cache.EventID

at 
org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:141)
at 
org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:108)
at 
org.apache.geode.internal.cache.BucketRegionQueueHelper.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueueHelper.java:50)
at 
org.apache.geode.internal.cache.wan.parallel.ParallelQueueRemovalMessageJUnitTest.validateDestroyKeyFromBucketQueueInUninitializedBucketRegionQueue(ParallelQueueRemovalMessageJUnitTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.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 

Re: Refactor gfsh parser

[Bruce Schuchardt]

+1
What other options like "member" exist that need to be modified?

Le 4/20/2017 à 1:37 PM, Jinmei Liao a écrit :

In the effort of adding option validation to gfsh commands (GEODE-1597) and
simplifying gfsh parsing, I started this exercise of only using
SpringShell's parser instead of a combination of springshell's,
joptsimple's and our own parsers. The end result is a lot more manageable
code base,  and the capability to validate the option list, but does have
these following different behaviors, and I would like the community's wight
in on whether or not these are acceptable or not:

1) SpringShell doesn't allow you to specify an option twice, so for
multivalued parameters, our old parser can accept command like

"change loglevel --member=member1 --member=member2",

but now the parser will give you an error, and you should only do
"change loglevel --member=member1,member2".

The new parser did something speical for --J option though, so for --J, you
can specify it multiple times.
2) For value separator, springShell default's to ",", you can only
overwrite it with option context "splittingRegex", we do not honor the
@CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
separators, so this won't break our commands, but if there is any command
out there that would define a different @CliMetaData(valueSepartor=) other
than ",", SpringShell would not know how to parse it.
3) To specify empty string as parameter value, before you will need to do

put region=A key="''" value="''"

spring shell would think the value you are trying to pass in are two single
quotes instead of empty strings, now, you should only do

put region=A key="" value=""

Cheers

Jinmei

Re: Refactor gfsh parser

[Swapnil Bawaskar]

+1

On Thu, Apr 20, 2017 at 2:34 PM Kirk Lund  wrote:

> These changes look great. Thanks!
>
> On Thu, Apr 20, 2017 at 1:37 PM, Jinmei Liao  wrote:
>
> > In the effort of adding option validation to gfsh commands (GEODE-1597)
> and
> > simplifying gfsh parsing, I started this exercise of only using
> > SpringShell's parser instead of a combination of springshell's,
> > joptsimple's and our own parsers. The end result is a lot more manageable
> > code base,  and the capability to validate the option list, but does have
> > these following different behaviors, and I would like the community's
> wight
> > in on whether or not these are acceptable or not:
> >
> > 1) SpringShell doesn't allow you to specify an option twice, so for
> > multivalued parameters, our old parser can accept command like
> >
> > "change loglevel --member=member1 --member=member2",
> >
> > but now the parser will give you an error, and you should only do
> > "change loglevel --member=member1,member2".
> >
> > The new parser did something speical for --J option though, so for --J,
> you
> > can specify it multiple times.
> > 2) For value separator, springShell default's to ",", you can only
> > overwrite it with option context "splittingRegex", we do not honor the
> > @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
> > separators, so this won't break our commands, but if there is any command
> > out there that would define a different @CliMetaData(valueSepartor=)
> other
> > than ",", SpringShell would not know how to parse it.
> > 3) To specify empty string as parameter value, before you will need to do
> >
> > put region=A key="''" value="''"
> >
> > spring shell would think the value you are trying to pass in are two
> single
> > quotes instead of empty strings, now, you should only do
> >
> > put region=A key="" value=""
> >
> > Cheers
> >
> > Jinmei
> >
>

Re: Refactor gfsh parser

[Kirk Lund]

These changes look great. Thanks!

On Thu, Apr 20, 2017 at 1:37 PM, Jinmei Liao  wrote:

> In the effort of adding option validation to gfsh commands (GEODE-1597) and
> simplifying gfsh parsing, I started this exercise of only using
> SpringShell's parser instead of a combination of springshell's,
> joptsimple's and our own parsers. The end result is a lot more manageable
> code base,  and the capability to validate the option list, but does have
> these following different behaviors, and I would like the community's wight
> in on whether or not these are acceptable or not:
>
> 1) SpringShell doesn't allow you to specify an option twice, so for
> multivalued parameters, our old parser can accept command like
>
> "change loglevel --member=member1 --member=member2",
>
> but now the parser will give you an error, and you should only do
> "change loglevel --member=member1,member2".
>
> The new parser did something speical for --J option though, so for --J, you
> can specify it multiple times.
> 2) For value separator, springShell default's to ",", you can only
> overwrite it with option context "splittingRegex", we do not honor the
> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
> separators, so this won't break our commands, but if there is any command
> out there that would define a different @CliMetaData(valueSepartor=) other
> than ",", SpringShell would not know how to parse it.
> 3) To specify empty string as parameter value, before you will need to do
>
> put region=A key="''" value="''"
>
> spring shell would think the value you are trying to pass in are two single
> quotes instead of empty strings, now, you should only do
>
> put region=A key="" value=""
>
> Cheers
>
> Jinmei
>

Re: Refactor gfsh parser

[Michael Stolz]

I see no issues with these changes.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Apr 20, 2017 4:38 PM, "Jinmei Liao"  wrote:

> In the effort of adding option validation to gfsh commands (GEODE-1597) and
> simplifying gfsh parsing, I started this exercise of only using
> SpringShell's parser instead of a combination of springshell's,
> joptsimple's and our own parsers. The end result is a lot more manageable
> code base,  and the capability to validate the option list, but does have
> these following different behaviors, and I would like the community's wight
> in on whether or not these are acceptable or not:
>
> 1) SpringShell doesn't allow you to specify an option twice, so for
> multivalued parameters, our old parser can accept command like
>
> "change loglevel --member=member1 --member=member2",
>
> but now the parser will give you an error, and you should only do
> "change loglevel --member=member1,member2".
>
> The new parser did something speical for --J option though, so for --J, you
> can specify it multiple times.
> 2) For value separator, springShell default's to ",", you can only
> overwrite it with option context "splittingRegex", we do not honor the
> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
> separators, so this won't break our commands, but if there is any command
> out there that would define a different @CliMetaData(valueSepartor=) other
> than ",", SpringShell would not know how to parse it.
> 3) To specify empty string as parameter value, before you will need to do
>
> put region=A key="''" value="''"
>
> spring shell would think the value you are trying to pass in are two single
> quotes instead of empty strings, now, you should only do
>
> put region=A key="" value=""
>
> Cheers
>
> Jinmei
>

[jira] [Commented] (GEODE-510) Bug48571DUnitTest.testStatsMatchWithSize failed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-510:
---

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

GEODE-510 Bug48571DUnitTest.testStatsMatchWithSize failed

This ticket was marked fixed in early 2016 but the Flaky annotation was
never removed and it was reopened by Anthony with no comment.  I'm removing
the Flaky annotation and closing the ticket.


> Bug48571DUnitTest.testStatsMatchWithSize failed
> ---
>
> Key: GEODE-510
> URL: https://issues.apache.org/jira/browse/GEODE-510
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: xiaojian zhou
>  Labels: CI, Flaky
> Fix For: 1.0.0-incubating.M3, 1.2.0
>
>
> revision d08e51d2eaa391fcda11cd18ee4413aa5fe6b80d
> {noformat}
> dunit.RMIException: While invoking 
> com.gemstone.gemfire.internal.cache.ha.Bug48571DUnitTest.createClientCache in 
> VM 1 running on Host venezuela.gemstone.com with 4 VMs
>   at dunit.VM.invoke(VM.java:170)
>   at 
> com.gemstone.gemfire.internal.cache.ha.Bug48571DUnitTest.testStatsMatchWithSize(Bug48571DUnitTest.java:99)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   at sun.reflect.GeneratedMethodAccessor176.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
>   at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: 
> com.gemstone.gemfire.cache.NoSubscriptionServersAvailableException: Could not 
> initialize a 

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit aaef124e3d4d7b46c82ddb4d2af65ee48b73ba53 in geode's branch 
refs/heads/feature/GEODE-2632-5 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=aaef124 ]

GEODE-728: Rename Execution.withArgs to Execution.setArguments

 * created setArguments
 * deprecated withArgs
 * implemented setArguments of all Execution implementations in Geode project
 * replaced all of withArgs with setArguments

This closes #457


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

[jira] [Commented] (GEODE-2796) NPE in ClassPathLoader

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2796:


Commit 48d662aab7ae4110f36a05aadefe9c12b48c1293 in geode's branch 
refs/heads/feature/GEODE-2632-5 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=48d662a ]

GEODE-2796: ClassPathLoader does not blow up with null TCCL


> NPE in ClassPathLoader
> --
>
> Key: GEODE-2796
> URL: https://issues.apache.org/jira/browse/GEODE-2796
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> It looks like an NPE was introduced by the fix for GEODE-2290:
> {noformat}
> Caused by: java.lang.NullPointerException
> at 
> org.apache.geode.internal.ClassPathLoader.getResource(ClassPathLoader.java:130)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:239)
> at 
> org.apache.geode.internal.ClassPathLoader.getResourceAsStream(ClassPathLoader.java:264)
> at 
> org.apache.geode.internal.GemFireVersion$VersionDescription.(GemFireVersion.java:191)
> at 
> org.apache.geode.internal.GemFireVersion.getDescription(GemFireVersion.java:52)
> at 
> org.apache.geode.internal.GemFireVersion.getGemFireVersion(GemFireVersion.java:66)
> at org.apache.geode.cache.CacheFactory.getVersion(CacheFactory.java:305)
> ...
> {noformat}
> This is caused by the following method: 
> {noformat}
>  private List getClassLoaders() {
> ArrayList classLoaders = new ArrayList<>();
> if (!excludeTCCL) {
>   classLoaders.add(Thread.currentThread().getContextClassLoader());
> }
> classLoaders.add(classLoaderForDeployedJars);
> return classLoaders;
>   }
> {noformat}
> According to the JavaDocs, `getContextClassLoader()` actually returns null to 
> indicate the system class loader (rather than actually returning the system 
> class loader).



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

[jira] [Commented] (GEODE-2681) Gfsh show missing-disk-stores command hangs when server is waiting for disk stores

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2681:


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

GEODE-2681: refactoring to prevent yncronization hang on getAnyInstance


> Gfsh show missing-disk-stores command hangs when server is waiting for disk 
> stores
> --
>
> Key: GEODE-2681
> URL: https://issues.apache.org/jira/browse/GEODE-2681
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
>Assignee: Kenneth Howe
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> Similar to GEODE-2680:
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  
> When trying to show missing disk stores in a different gfsh process, this 
> command also hangs.  It is expected that this process should not be hung
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Attempt to start a separate gfsh process and run the following commands:
> 1.) connect
> 2.) show missing-disk-stores



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

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit 5891ed7c4306e761c1f12edf85401ab140429d04 in geode's branch 
refs/heads/feature/GEODE-2632-5 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5891ed7 ]

GEODE-728: Using the correct parameter in withArgs

ServerRegionFunctionExecutor.withArgs was not using it's argument, it
was just passing the (null) field named args to setArguments.


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

Re: Review Request 58544: GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

[Kirk Lund]

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

(Updated April 20, 2017, 9:21 p.m.)


Review request for geode, Jason Huynh, Jinmei Liao, Jared Stewart, Ken Howe, 
and Dan Smith.


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


Repository: geode


Description
---

GEODE-2632 refactoring part 5

GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

* minor cleanup: delete dead-code and useless javadocs/comments, reduce scope 
of vars/methods/constants, misc IDE warnings


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceProvider.java
 cded9c319e9731f74fb6ec14a7f4a02187ae1603 
  
geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/spi/CqServiceFactory.java
 68ebbd54d4d2459ec8df27b15ace8c83942723f6 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/ClientCQImpl.java
 00a0aa5a9e7d8f770f2253e2c48dc6319d6864e3 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqQueryImpl.java
 22b4137c0d52bd84749b9617163b8723d1249ab6 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceFactoryImpl.java
 db90632437c80879b3ab213bbad34018809f1c31 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceImpl.java
 f1ca8328ad9b9c67e70292093f117cc885d911b5 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceStatisticsImpl.java
 ba71143cb271bd177b21e22e00d22a34f69c2834 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceVsdStats.java
 8435c4cea87401a6d29afc65d367d774dc3f4bf6 
  
geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/ServerCQImpl.java
 ec6e984e24b3dcdf40628bb6f510d0ff96a800f5 
  
geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ExecuteCQ.java
 bcf98063c8ccf7c3d8ba44c9868b8921bb49a64b 
  
geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ExecuteCQ61.java
 f333b4bdafdadad53060fe11ae9d98cc4f4593d4 
  
geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetDurableCQs.java
 eac9ed3ad2da2afa92e1230d17b550301631307e 
  
geode-cq/src/test/java/org/apache/geode/cache/query/cq/dunit/CqStatsDUnitTest.java
 7ace0e8e54bedf94622af5f011627a97c6316dd1 
  
geode-cq/src/test/java/org/apache/geode/cache/query/cq/dunit/CqStatsUsingPoolDUnitTest.java
 d6068f1ecc88c076c3d1a8dbd3e3bc944766fbaa 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesFunctionCollector.java
 66c4c0a298156926793f66eee1ac3efc85b27a14 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunctionJUnitTest.java
 5313cedd48fa337ef9390a1659ed52dc9d9a0c77 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesCollectorJUnitTest.java
 3bfebdf2e3b213b6e8b89075f7510f8dc7fbfb4d 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesFunctionCollectorJUnitTest.java
 bf08877bf4cb1c8be07d69bd0bbdb529a2b2c340 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesJUnitTest.java
 fcfebbcb9b46a7beedecc661c31c71836df34dc2 
  
geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
 556311214371270259c024d565a6b4f0fa6a2146 


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


Testing (updated)
---

precheckin passed except for FixedPRSinglehopDUnitTest which passes in rerun


Thanks,

Kirk Lund

Re: Review Request 58582: GEODE-2632: 1st pass cleaning up GemFireCacheImpl

[Kirk Lund]

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

(Updated April 20, 2017, 9:19 p.m.)


Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, and Ken 
Howe.


Changes
---

Fix compilation errors. I thought I did a full non-testing build before 
submitting review (oops).


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


Repository: geode


Description
---

GEODE-2632: 1st pass cleaning up GemFireCacheImpl

* remove dead-code
* add @Override annotations
* remove uselss javadocs and comments
* reduce scope of constants/vars/methods where possible
* fix misc IDE warnings
* remove unused imports (and reorg imports)

This turned out to be a big diff so I'm submitting a separate review just for 
this cleanup.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyCache.java 
76306f51fc9479c7d9acaa28022ed908b674b7c0 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
709308b57da847845ef9319bece18ebe9f25e569 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 a5f0fc2bc7cf4250565aa8dd139004890b8da07d 
  
geode-core/src/main/java/org/apache/geode/management/internal/beans/MemberMBeanBridge.java
 d6a1efa73028e1b9514db67d2e3a4b564abee632 
  geode-core/src/test/java/org/apache/geode/TXJUnitTest.java 
54d9e503f2645d045487cea51011143602764f62 
  geode-core/src/test/java/org/apache/geode/TXWriterTestCase.java 
987f22f688ca695a8b37eacf239c69c329bb3b3b 
  geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterJUnitTest.java 
0a61b1f258d090090321c9ccff1a25781da7c8d1 
  
geode-core/src/test/java/org/apache/geode/disttx/DistTXWriterOOMEJUnitTest.java 
b99d3fd25cdac5f1862927d098d9d6381894510e 
  geode-core/src/test/java/org/apache/geode/internal/cache/PRTXJUnitTest.java 
d2bad641a47f68edb22da0f89a04c462ab48cd33 


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

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

Commit 5891ed7c4306e761c1f12edf85401ab140429d04 in geode's branch 
refs/heads/feature/GEODE-2632-6 from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5891ed7 ]

GEODE-728: Using the correct parameter in withArgs

ServerRegionFunctionExecutor.withArgs was not using it's argument, it
was just passing the (null) field named args to setArguments.


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

Re: Refactor gfsh parser

[John Blum]

+1, I agree with Jens; The option could be renamed to '--members' and mean
1 or more.

On Thu, Apr 20, 2017 at 2:00 PM, Jens Deppe  wrote:

> IMO I much prefer having:
>
> --member=member1,member2
>
> vs:
>
> --member=member1 --member=member2
>
> The latter can leave me wondering if subsequent values are additive or
> actually override prior ones.
>
> --Jens
>
>
> On Thu, Apr 20, 2017 at 1:37 PM, Jinmei Liao  wrote:
>
> > In the effort of adding option validation to gfsh commands (GEODE-1597)
> and
> > simplifying gfsh parsing, I started this exercise of only using
> > SpringShell's parser instead of a combination of springshell's,
> > joptsimple's and our own parsers. The end result is a lot more manageable
> > code base,  and the capability to validate the option list, but does have
> > these following different behaviors, and I would like the community's
> wight
> > in on whether or not these are acceptable or not:
> >
> > 1) SpringShell doesn't allow you to specify an option twice, so for
> > multivalued parameters, our old parser can accept command like
> >
> > "change loglevel --member=member1 --member=member2",
> >
> > but now the parser will give you an error, and you should only do
> > "change loglevel --member=member1,member2".
> >
> > The new parser did something speical for --J option though, so for --J,
> you
> > can specify it multiple times.
> > 2) For value separator, springShell default's to ",", you can only
> > overwrite it with option context "splittingRegex", we do not honor the
> > @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
> > separators, so this won't break our commands, but if there is any command
> > out there that would define a different @CliMetaData(valueSepartor=)
> other
> > than ",", SpringShell would not know how to parse it.
> > 3) To specify empty string as parameter value, before you will need to do
> >
> > put region=A key="''" value="''"
> >
> > spring shell would think the value you are trying to pass in are two
> single
> > quotes instead of empty strings, now, you should only do
> >
> > put region=A key="" value=""
> >
> > Cheers
> >
> > Jinmei
> >
>



-- 
-John
john.blum10101 (skype)

Review Request 58594: even lost primary, dispatched batch should still be removed

[xiaojian zhou]

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

Review request for geode and Jason Huynh.


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


Repository: geode


Description
---

one of the known root causes


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
 cf4c5a9ef 


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


Testing
---


Thanks,

xiaojian zhou

[jira] [Assigned] (GEODE-2806) when batch is dispatched, if the bucket is not primary, we should still destroy the event from queue

[xiaojian zhou (JIRA)]

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

xiaojian zhou reassigned GEODE-2806:


Assignee: xiaojian zhou

> when batch is dispatched, if the bucket is not primary, we should still 
> destroy the event from queue
> 
>
> Key: GEODE-2806
> URL: https://issues.apache.org/jira/browse/GEODE-2806
> Project: Geode
>  Issue Type: Bug
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>  Labels: lucene
>
> This is one of the root causes for data mismatch. 
> When AEQ dispatched a batch, when it tried to destroy the events from queue, 
> the bucket might be no longer primary. There's no need to let the new primary 
> to re-dispatch the batch. 



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

[jira] [Created] (GEODE-2806) when batch is dispatched, if the bucket is not primary, we should still destroy the event from queue

[xiaojian zhou (JIRA)]

xiaojian zhou created GEODE-2806:


 Summary: when batch is dispatched, if the bucket is not primary, 
we should still destroy the event from queue
 Key: GEODE-2806
 URL: https://issues.apache.org/jira/browse/GEODE-2806
 Project: Geode
  Issue Type: Bug
Reporter: xiaojian zhou


This is one of the root causes for data mismatch. 

When AEQ dispatched a batch, when it tried to destroy the events from queue, 
the bucket might be no longer primary. There's no need to let the new primary 
to re-dispatch the batch. 



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

Re: Refactor gfsh parser

[Jens Deppe]

IMO I much prefer having:

--member=member1,member2

vs:

--member=member1 --member=member2

The latter can leave me wondering if subsequent values are additive or
actually override prior ones.

--Jens


On Thu, Apr 20, 2017 at 1:37 PM, Jinmei Liao  wrote:

> In the effort of adding option validation to gfsh commands (GEODE-1597) and
> simplifying gfsh parsing, I started this exercise of only using
> SpringShell's parser instead of a combination of springshell's,
> joptsimple's and our own parsers. The end result is a lot more manageable
> code base,  and the capability to validate the option list, but does have
> these following different behaviors, and I would like the community's wight
> in on whether or not these are acceptable or not:
>
> 1) SpringShell doesn't allow you to specify an option twice, so for
> multivalued parameters, our old parser can accept command like
>
> "change loglevel --member=member1 --member=member2",
>
> but now the parser will give you an error, and you should only do
> "change loglevel --member=member1,member2".
>
> The new parser did something speical for --J option though, so for --J, you
> can specify it multiple times.
> 2) For value separator, springShell default's to ",", you can only
> overwrite it with option context "splittingRegex", we do not honor the
> @CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
> separators, so this won't break our commands, but if there is any command
> out there that would define a different @CliMetaData(valueSepartor=) other
> than ",", SpringShell would not know how to parse it.
> 3) To specify empty string as parameter value, before you will need to do
>
> put region=A key="''" value="''"
>
> spring shell would think the value you are trying to pass in are two single
> quotes instead of empty strings, now, you should only do
>
> put region=A key="" value=""
>
> Cheers
>
> Jinmei
>

Refactor gfsh parser

[Jinmei Liao]

In the effort of adding option validation to gfsh commands (GEODE-1597) and
simplifying gfsh parsing, I started this exercise of only using
SpringShell's parser instead of a combination of springshell's,
joptsimple's and our own parsers. The end result is a lot more manageable
code base,  and the capability to validate the option list, but does have
these following different behaviors, and I would like the community's wight
in on whether or not these are acceptable or not:

1) SpringShell doesn't allow you to specify an option twice, so for
multivalued parameters, our old parser can accept command like

"change loglevel --member=member1 --member=member2",

but now the parser will give you an error, and you should only do
"change loglevel --member=member1,member2".

The new parser did something speical for --J option though, so for --J, you
can specify it multiple times.
2) For value separator, springShell default's to ",", you can only
overwrite it with option context "splittingRegex", we do not honor the
@CliMetaData(valueSepartor=) anymore. All of our commands uses "," for
separators, so this won't break our commands, but if there is any command
out there that would define a different @CliMetaData(valueSepartor=) other
than ",", SpringShell would not know how to parse it.
3) To specify empty string as parameter value, before you will need to do

put region=A key="''" value="''"

spring shell would think the value you are trying to pass in are two single
quotes instead of empty strings, now, you should only do

put region=A key="" value=""

Cheers

Jinmei

[jira] [Commented] (GEODE-72) Remove deprecated APIs from Geode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-72:
-

Github user davinash closed the pull request at:

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


> Remove deprecated APIs from Geode
> -
>
> Key: GEODE-72
> URL: https://issues.apache.org/jira/browse/GEODE-72
> Project: Geode
>  Issue Type: Improvement
>Affects Versions: 1.0.0-incubating
>Reporter: Bruce Schuchardt
>  Labels: cleanup, docs
>
> The Geode APIs are riddled with old, deprecated interfaces, methods and 
> settings inherited from GemFire.  Unless there is a good reason to keep them 
> shouldn't we remove them all before going out of incubation?
> Sub-tasks have been added for most items. Here are the remaining items not 
> yet added:
> APIs deprecated in GemFire 5.1:
> * DLS.lockInterruptibly(), suspendLockingInterruptibly()
>  
> APIs deprecated in an undocumented version prior to 5.7:
> * Use of hostname:port to specify a locator in gemfire.properties
>   
> APIs deprecated after GemFire 5.7 and before 8.0
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we 
> never deprecated EvictionAttributes.createLIFOEntryAttributes
> nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used 
> internally by the product when a server create a queue to send subscription 
> events to a client (see BridgeServerImpl.clientMessagesRegion). I think the 
> algorithms were deprecated because we didn't intend to expose this internal 
> feature as an external one. But they are exposed externally via 
> EvictionAttributes so it is not clear that we can just delete them.
> The other consideration is that we do not have xsd support nor gfsh support 
> for LIFO.
> * Region.getCache(): we should consider un-deprecating this. Customers were 
> supposed to instead call Region.getRegionService but in lots of cases they 
> would need to down cast that result to "Cache". Only clients that are calling 
> ClientCache.createAuthenticatedView end up with Regions whose getCache throws 
> UnsupportedOperationException. Our code call getCache from over 500 places.
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), 
> getDiskTaskWaiting()
> Things that should be deprecated but are not:
> * MembershipAttributes and “required roles”.
> * DynamicRegions: if GEODE-215 is implemented then we could deprecate 
> DynamicRegions and have an alternative to change to. We have some support in 
> the gfsh/management layer for creating regions remotely which might be good 
> enough to deprecate DynamicRegions. The question is should we remove 
> com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been 
> deprecated.
> Deprecated in 7.0 and not previously in this list:
> * UniversalMembershipListenerAdapter
> APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to 
> keep these for a while to allow people to migrate from their GemFire product 
> to Geode.
> * PutAllOperationContext.setMap()
> * FixedPartitionResolver.getPartitionName(EntryOperation, Set)
> * ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, 
> jmx-manager-ssl distribution properties
> * RegionMXBean.getAvgBucketSize()
> The Admin API and packages are also marked as deprecated but there seem to be 
> some gfsh dependencies on this API, so I'm not sure if it can be removed.
> Also consider removing com.gemstone.gemfire.cache.partition.PartitionListener 
> and com.gemstone.gemfire.cache.partition.PartitionManager.
> They have not been deprecated but were never fully supported. Their javadocs 
> say:
>   Note : Please contact supp...@gemstone.com before using these APIs



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

[jira] [Commented] (GEODE-72) Remove deprecated APIs from Geode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-72:
-

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/456
  
closing this PR, as I have opened separate PR for each subtask.


> Remove deprecated APIs from Geode
> -
>
> Key: GEODE-72
> URL: https://issues.apache.org/jira/browse/GEODE-72
> Project: Geode
>  Issue Type: Improvement
>Affects Versions: 1.0.0-incubating
>Reporter: Bruce Schuchardt
>  Labels: cleanup, docs
>
> The Geode APIs are riddled with old, deprecated interfaces, methods and 
> settings inherited from GemFire.  Unless there is a good reason to keep them 
> shouldn't we remove them all before going out of incubation?
> Sub-tasks have been added for most items. Here are the remaining items not 
> yet added:
> APIs deprecated in GemFire 5.1:
> * DLS.lockInterruptibly(), suspendLockingInterruptibly()
>  
> APIs deprecated in an undocumented version prior to 5.7:
> * Use of hostname:port to specify a locator in gemfire.properties
>   
> APIs deprecated after GemFire 5.7 and before 8.0
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we 
> never deprecated EvictionAttributes.createLIFOEntryAttributes
> nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used 
> internally by the product when a server create a queue to send subscription 
> events to a client (see BridgeServerImpl.clientMessagesRegion). I think the 
> algorithms were deprecated because we didn't intend to expose this internal 
> feature as an external one. But they are exposed externally via 
> EvictionAttributes so it is not clear that we can just delete them.
> The other consideration is that we do not have xsd support nor gfsh support 
> for LIFO.
> * Region.getCache(): we should consider un-deprecating this. Customers were 
> supposed to instead call Region.getRegionService but in lots of cases they 
> would need to down cast that result to "Cache". Only clients that are calling 
> ClientCache.createAuthenticatedView end up with Regions whose getCache throws 
> UnsupportedOperationException. Our code call getCache from over 500 places.
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), 
> getDiskTaskWaiting()
> Things that should be deprecated but are not:
> * MembershipAttributes and “required roles”.
> * DynamicRegions: if GEODE-215 is implemented then we could deprecate 
> DynamicRegions and have an alternative to change to. We have some support in 
> the gfsh/management layer for creating regions remotely which might be good 
> enough to deprecate DynamicRegions. The question is should we remove 
> com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been 
> deprecated.
> Deprecated in 7.0 and not previously in this list:
> * UniversalMembershipListenerAdapter
> APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to 
> keep these for a while to allow people to migrate from their GemFire product 
> to Geode.
> * PutAllOperationContext.setMap()
> * FixedPartitionResolver.getPartitionName(EntryOperation, Set)
> * ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, 
> jmx-manager-ssl distribution properties
> * RegionMXBean.getAvgBucketSize()
> The Admin API and packages are also marked as deprecated but there seem to be 
> some gfsh dependencies on this API, so I'm not sure if it can be removed.
> Also consider removing com.gemstone.gemfire.cache.partition.PartitionListener 
> and com.gemstone.gemfire.cache.partition.PartitionManager.
> They have not been deprecated but were never fully supported. Their javadocs 
> say:
>   Note : Please contact supp...@gemstone.com before using these APIs



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

[GitHub] geode pull request #456: GEODE-72 : Remove deprecated APIs from Geode

[davinash]

Github user davinash closed the pull request at:

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


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

[GitHub] geode issue #456: GEODE-72 : Remove deprecated APIs from Geode

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/456
  
closing this PR, as I have opened separate PR for each subtask.


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

Re: Review Request 58586: GEODE-2801: change krfIds to be thread safe

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 20, 2017, 6:44 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58586/
> ---
> 
> (Updated April 20, 2017, 6:44 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2801
> https://issues.apache.org/jira/browse/GEODE-2801
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Made this code theadsafe by changing krfIds to be a ConcurrentHashSet 
> instead of LongOpenHashSet.
> Also added a unit test to do basic validation of krfIds.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DiskInitFile.java 
> f6bf17f24ed2621731078d15bf59f1fd0326e3a9 
>   geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java 
> ca9468d503f5930fb20efa191335ba72d9b081ff 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/DiskInitFileJUnitTest.java
>  6f2cf6c8f0088c29d2e38603e9e90fa1948294b2 
> 
> 
> Diff: https://reviews.apache.org/r/58586/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

[jira] [Commented] (GEODE-267) Remove deprecated ThreadInterruptedException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-267:
--

GitHub user davinash opened a pull request:

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

GEODE-267: Remove deprecated ThreadInterruptedException



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

$ git pull https://github.com/davinash/geode feature/GEODE-267

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

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






> Remove deprecated ThreadInterruptedException
> 
>
> Key: GEODE-267
> URL: https://issues.apache.org/jira/browse/GEODE-267
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The ThreadInterruptedException is deprecated and should be removed. None of 
> our product code nor our test code uses it so it should be easy to remove.



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

[jira] [Commented] (GEODE-289) Remove deprecated LicenseException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-289:
--

GitHub user davinash opened a pull request:

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

GEODE-289: Remove depcreated LicenseException class



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

$ git pull https://github.com/davinash/geode feature/GEODE-289

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

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






> Remove deprecated LicenseException
> --
>
> Key: GEODE-289
> URL: https://issues.apache.org/jira/browse/GEODE-289
> Project: Geode
>  Issue Type: Sub-task
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Avinash Dongre
>
> com.gemstone.gemfire.LicenseException currently exists only for backwards 
> compatibility of user code. It should be removed from Geode.
> If GemFire requires it for backwards compatibility then it will be moved to 
> GemFire.



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

[jira] [Commented] (GEODE-266) Remove deprecated ObjectSizerImpl

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-266:
--

GitHub user davinash opened a pull request:

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

GEODE-266: Remove the deprecated ObjectSizerImpl class



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

$ git pull https://github.com/davinash/geode feature/GEODE-266

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

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






> Remove deprecated ObjectSizerImpl
> -
>
> Key: GEODE-266
> URL: https://issues.apache.org/jira/browse/GEODE-266
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Remove the deprecated ObjectSizerImpl class. It can simply be replaced with 
> ObjectSizer.DEFAULT. It is used in some tests but should be easy to remove.



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

[GitHub] geode pull request #469: GEODE-266: Remove the deprecated ObjectSizerImpl cl...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-266: Remove the deprecated ObjectSizerImpl class



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

$ git pull https://github.com/davinash/geode feature/GEODE-266

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

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






---
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-260) Remove deprecated RemoteTransactionException

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-260:
--

GitHub user davinash opened a pull request:

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

GEODE-260: Remove deprecated RemoteTransactionException



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

$ git pull https://github.com/davinash/geode feature/GEODE-260

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

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






> Remove deprecated RemoteTransactionException
> 
>
> Key: GEODE-260
> URL: https://issues.apache.org/jira/browse/GEODE-260
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> RemoteTransactionException is not used by any code so should be very easy to 
> remove.



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

[GitHub] geode pull request #468: GEODE-260: Remove deprecated RemoteTransactionExcep...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-260: Remove deprecated RemoteTransactionException



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

$ git pull https://github.com/davinash/geode feature/GEODE-260

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

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






---
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-258) Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-258:
--

GitHub user davinash opened a pull request:

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

GEODE-258: Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n 
methods  



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

$ git pull https://github.com/davinash/geode feature/GEODE-258

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

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






> Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods
> ---
>
> Key: GEODE-258
> URL: https://issues.apache.org/jira/browse/GEODE-258
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> Remove the deprecated Cache.getLoggerI18n and getSecurityLoggerI18n methods. 
> All calls can be replaced with getLogger().convertToLogWriterI18n() so this 
> should be a quick task.



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

[GitHub] geode pull request #467: GEODE-258: Remove deprecated Cache.getLoggerI18n an...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-258: Remove deprecated Cache.getLoggerI18n and getSecurityLoggerI18n 
methods  



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

$ git pull https://github.com/davinash/geode feature/GEODE-258

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

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






---
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-255) Remove deprecated DataSerializer.register(Class,byte)

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-255:
--

GitHub user davinash opened a pull request:

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

GEODE-255: Removed deprecated DataSerializer.register(Class,byte)

Removed deprecated DataSerializer.register(Class,byte)

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

$ git pull https://github.com/davinash/geode feature/GEODE-255

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

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






> Remove deprecated DataSerializer.register(Class,byte)
> -
>
> Key: GEODE-255
> URL: https://issues.apache.org/jira/browse/GEODE-255
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Remove the deprecated DataSerializer.register(Class,byte) method.
> It should be simple to change all callers to DataSerializer.register(Class) 
> since the current implementation does that.



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

[jira] [Commented] (GEODE-253) Remove deprecated EntryNotFoundInRegion

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-253:
--

GitHub user davinash opened a pull request:

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

GEODE-253: Removed depreated and not used EntryNotFoundInRegion class

Removed depreated and not used EntryNotFoundInRegion class

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

$ git pull https://github.com/davinash/geode feature/GEODE-253

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

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






> Remove deprecated EntryNotFoundInRegion
> ---
>
> Key: GEODE-253
> URL: https://issues.apache.org/jira/browse/GEODE-253
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The EntryNotFoundInRegion is not used at all so should be very easy to remove.



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

[GitHub] geode pull request #466: GEODE-255: Removed deprecated DataSerializer.regist...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-255: Removed deprecated DataSerializer.register(Class,byte)

Removed deprecated DataSerializer.register(Class,byte)

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

$ git pull https://github.com/davinash/geode feature/GEODE-255

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

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






---
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-237) Remove EntryEvent deprecated methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-237:
--

GitHub user davinash opened a pull request:

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

GEODE-237: Removed deprecated API from EntryEvent

Removed deprecated CacheEvent methods

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

$ git pull https://github.com/davinash/geode feature/GEODE-237

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

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


commit 69c7d997c340efe9cfd3ba755f529ee113d1e2ad
Author: adongre 
Date:   2017-04-19T08:41:49Z

GEODE-237: Removed deprecated API from EntryEvent
1. isLocalLoad
2. isNetLoad
3. isLoad
4. isNetSearch
5. isBridgeEvent




> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



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

[GitHub] geode pull request #465: GEODE-253: Removed depreated and not used EntryNotF...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-253: Removed depreated and not used EntryNotFoundInRegion class

Removed depreated and not used EntryNotFoundInRegion class

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

$ git pull https://github.com/davinash/geode feature/GEODE-253

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

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






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

[GitHub] geode pull request #464: GEODE-237: Removed deprecated API from EntryEvent

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-237: Removed deprecated API from EntryEvent

Removed deprecated CacheEvent methods

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

$ git pull https://github.com/davinash/geode feature/GEODE-237

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

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


commit 69c7d997c340efe9cfd3ba755f529ee113d1e2ad
Author: adongre 
Date:   2017-04-19T08:41:49Z

GEODE-237: Removed deprecated API from EntryEvent
1. isLocalLoad
2. isNetLoad
3. isLoad
4. isNetSearch
5. isBridgeEvent




---
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-236) Remove deprecated CacheEvent methods

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-236:
--

GitHub user davinash opened a pull request:

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

GEODE-236: Removed deprecated CacheEvent methods

Removed deprecated CacheEvent methods

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

$ git pull https://github.com/davinash/geode feature/GEODE-236

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

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


commit f9cd9793efcfa8fb40c0fef03b88ee8689114a2a
Author: adongre 
Date:   2017-04-19T10:19:43Z

GEODE-236: Removed deprecated CacheEvent methods




> Remove deprecated CacheEvent methods
> 
>
> Key: GEODE-236
> URL: https://issues.apache.org/jira/browse/GEODE-236
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following methods need to be removed:
> - CacheEvent.isExpiration: change to CacheEvent.getOperation().isExpiration
> - CacheEvent.isDistributed: change to CacheEvent.getOperation().isDistributed
> This should be a pretty easy task to complete.



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

[GitHub] geode pull request #463: GEODE-236: Removed deprecated CacheEvent methods

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-236: Removed deprecated CacheEvent methods

Removed deprecated CacheEvent methods

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

$ git pull https://github.com/davinash/geode feature/GEODE-236

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

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


commit f9cd9793efcfa8fb40c0fef03b88ee8689114a2a
Author: adongre 
Date:   2017-04-19T10:19:43Z

GEODE-236: Removed deprecated CacheEvent methods




---
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-2805) disk store backup may not include krf files for the oplogs it backs up

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2805:
---

 Summary: disk store backup may not include krf files for the 
oplogs it backs up
 Key: GEODE-2805
 URL: https://issues.apache.org/jira/browse/GEODE-2805
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


I believe a race condition exists that will cause a disk store backup to not 
backup one or more krf files for the oplogs it backs up. You can still restore 
from this backup but the recovery may go much slower.

Backup should be changed to wait for the async krf creation to complete instead 
of skipping over that krf file. I think this can be done in Oplog.java at the 
spot it currently calls "hasKrf". I think that if it instead first called 
"finishKrf" that it would wait for an in-progress krf creation to finish.




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

Review Request 58586: GEODE-2801: change krfIds to be thread safe

[Darrel Schneider]

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

Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.


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


Repository: geode


Description
---

Made this code theadsafe by changing krfIds to be a ConcurrentHashSet 
instead of LongOpenHashSet.
Also added a unit test to do basic validation of krfIds.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/cache/DiskInitFile.java 
f6bf17f24ed2621731078d15bf59f1fd0326e3a9 
  geode-core/src/main/java/org/apache/geode/internal/cache/Oplog.java 
ca9468d503f5930fb20efa191335ba72d9b081ff 
  
geode-core/src/test/java/org/apache/geode/internal/cache/DiskInitFileJUnitTest.java
 6f2cf6c8f0088c29d2e38603e9e90fa1948294b2 


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


Testing
---

precheckin


Thanks,

Darrel Schneider

[jira] [Updated] (GEODE-1561) CI Failure: GemfireDataCommandsDUnitTest.testSimulateForEntireDS assertion failure

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-1561:

Component/s: (was: rest (dev))
 rest (admin)

> CI Failure:  GemfireDataCommandsDUnitTest.testSimulateForEntireDS assertion 
> failure
> ---
>
> Key: GEODE-1561
> URL: https://issues.apache.org/jira/browse/GEODE-1561
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin)
>Reporter: Scott Jewell
>Assignee: Jinmei Liao
>  Labels: CI, Flaky
>
> Error Message
> java.lang.AssertionError: expected: but was:
> Stacktrace
> java.lang.AssertionError: expected: but was:
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:118)
>   at org.junit.Assert.assertEquals(Assert.java:144)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.GemfireDataCommandsDUnitTest.testSimulateForEntireDS(GemfireDataCommandsDUnitTest.java:1831)
>   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.ExternalResource$1.evaluate(ExternalResource.java:48)
>   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.junit.runners.Suite.runChild(Suite.java:128)
>   at org.junit.runners.Suite.runChild(Suite.java:27)
>   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.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> 

Re: Review Request 58541: GEODE-576 & GEODE-516 Flaky test: GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithFunction

[Hitesh Khamesra]

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


Ship it!




Ship It!

- Hitesh Khamesra


On April 19, 2017, 8:27 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58541/
> ---
> 
> (Updated April 19, 2017, 8:27 p.m.)
> 
> 
> Review request for geode, Galen O'Sullivan, Hitesh Khamesra, Udo Kohlmeyer, 
> and Dan Smith.
> 
> 
> Bugs: GEODE-516 and GEODE-576
> https://issues.apache.org/jira/browse/GEODE-516
> https://issues.apache.org/jira/browse/GEODE-576
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Replaced pauses with Awaitility.  Modified asyncs to use the DUnit blackboard 
> to synchronize their actions for repeatable behavior.  Cleaned up static 
> locks to allow their reuse in other tests or in repeating the same test.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  e0bbde06ba2ce8e8db55627920ee6cf23e4badb2 
> 
> 
> Diff: https://reviews.apache.org/r/58541/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[jira] [Updated] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-2804:

Affects Version/s: 1.1.1

> Allow a locator host to be taken off line and replaced with a different 
> machine having the same host name
> -
>
> Key: GEODE-2804
> URL: https://issues.apache.org/jira/browse/GEODE-2804
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, membership, native client
>Affects Versions: 1.1.1
>Reporter: Bruce Schuchardt
>
> It is not unlikely that in a long-running system a machine hosting a locator 
> will break down and need to be replace, or that a virtual machine hosting a 
> locator will be stopped and restarted.  In either case the machine may have a 
> different IP address.
> Clients and servers currently cache the IP address of a locator and should be 
> changed to re-resolve the host name if the address stops being usable.
> Servers currently cannot be started if they are given a host name that can 
> not be resolved.  They should be changed to allow this and start up if they 
> are able to contact one or more of the other locators in their "locators" 
> setting.



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

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

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

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

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/450
  
@upthewaterspout thoughts?


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

[metatype]

Github user metatype commented on the issue:

https://github.com/apache/geode/pull/450
  
@upthewaterspout thoughts?


---
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-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

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

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

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
@galen-pivotal I don't know enough about "DuplicatesStrategy.WARN" but it 
gets printed because JMH is pulling in all dependencies from all geode modules 
and the way we have our gradle build setup, this results in duplicates of some 
dependencies and even some of our own code. Getting rid of that will require 
someone with more gradle knowledge (if it's even possible).


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
@galen-pivotal I don't know enough about "DuplicatesStrategy.WARN" but it 
gets printed because JMH is pulling in all dependencies from all geode modules 
and the way we have our gradle build setup, this results in duplicates of some 
dependencies and even some of our own code. Getting rid of that will require 
someone with more gradle knowledge (if it's even possible).


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

[GitHub] geode pull request #450: GEODE-2632: create ClientCachePutBench

[kirklund]

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

https://github.com/apache/geode/pull/450#discussion_r112522440
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,233 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of single-threaded client performing 
puts to a loner server.
+ * 
+ * 100 random keys and values are generated during setup and the client 
reuses these in order,
+ * looping back around after 100 puts.
+ */
+@Measurement(iterations = 3, time = 2, timeUnit = MINUTES)
+@Warmup(iterations = 1, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final int NUMBER_OF_KEYS = 100;
+  static final int NUMBER_OF_VALUES = 100;
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Region region;
+
+String[] keys;
+String[] values;
+
+private int keyIndex = -1;
+private int valueIndex = -1;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+ 

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/450#discussion_r112522440
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,233 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of single-threaded client performing 
puts to a loner server.
+ * 
+ * 100 random keys and values are generated during setup and the client 
reuses these in order,
+ * looping back around after 100 puts.
+ */
+@Measurement(iterations = 3, time = 2, timeUnit = MINUTES)
+@Warmup(iterations = 1, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final int NUMBER_OF_KEYS = 100;
+  static final int NUMBER_OF_VALUES = 100;
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Region region;
+
+String[] keys;
+String[] values;
+
+private int keyIndex = -1;
+private int valueIndex = -1;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private 

Re: Review Request 58582: GEODE-2632: 1st pass cleaning up GemFireCacheImpl

[Kirk Lund]

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

(Updated April 20, 2017, 6:01 p.m.)


Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, and Ken 
Howe.


Changes
---

Use spotlessApply


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


Repository: geode


Description
---

GEODE-2632: 1st pass cleaning up GemFireCacheImpl

* remove dead-code
* add @Override annotations
* remove uselss javadocs and comments
* reduce scope of constants/vars/methods where possible
* fix misc IDE warnings
* remove unused imports (and reorg imports)

This turned out to be a big diff so I'm submitting a separate review just for 
this cleanup.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
709308b57da847845ef9319bece18ebe9f25e569 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 a5f0fc2bc7cf4250565aa8dd139004890b8da07d 


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

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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-728:
---

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

GEODE-728: Using the correct parameter in withArgs

ServerRegionFunctionExecutor.withArgs was not using it's argument, it
was just passing the (null) field named args to setArguments.


> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
> Fix For: 1.2.0
>
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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

Review Request 58582: GEODE-2632: 1st pass cleaning up GemFireCacheImpl

[Kirk Lund]

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

Review request for geode, Darrel Schneider, Jinmei Liao, Jared Stewart, and Ken 
Howe.


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


Repository: geode


Description
---

GEODE-2632: 1st pass cleaning up GemFireCacheImpl

* remove dead-code
* add @Override annotations
* remove uselss javadocs and comments
* reduce scope of constants/vars/methods where possible
* fix misc IDE warnings
* remove unused imports (and reorg imports)

This turned out to be a big diff so I'm submitting a separate review just for 
this cleanup.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
56243e1b544f5958204e64c2ca391003aa1fd098 
  geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
709308b57da847845ef9319bece18ebe9f25e569 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheCreation.java
 a5f0fc2bc7cf4250565aa8dd139004890b8da07d 


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


Testing
---

precheckin in progress


Thanks,

Kirk Lund

Re: Review Request 58518: GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On April 19, 2017, 11:22 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58518/
> ---
> 
> (Updated April 19, 2017, 11:22 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'
> 
> - LocatorServerStarterRule will now always bounce the DUnit VMs in after() to 
> prevent corrupted cached values of `System.getProperty('user.dir')` that 
> refer to a temporary folder which no longer exists.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  d47b343 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
>  c5aaa74 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  34506c4 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
> 05e541a 
> 
> 
> Diff: https://reviews.apache.org/r/58518/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Created] (GEODE-2804) Allow a locator host to be taken off line and replaced with a different machine having the same host name

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-2804:
---

 Summary: Allow a locator host to be taken off line and replaced 
with a different machine having the same host name
 Key: GEODE-2804
 URL: https://issues.apache.org/jira/browse/GEODE-2804
 Project: Geode
  Issue Type: Improvement
  Components: client/server, membership, native client
Reporter: Bruce Schuchardt


It is not unlikely that in a long-running system a machine hosting a locator 
will break down and need to be replace, or that a virtual machine hosting a 
locator will be stopped and restarted.  In either case the machine may have a 
different IP address.

Clients and servers currently cache the IP address of a locator and should be 
changed to re-resolve the host name if the address stops being usable.

Servers currently cannot be started if they are given a host name that can not 
be resolved.  They should be changed to allow this and start up if they are 
able to contact one or more of the other locators in their "locators" setting.



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

Re: Review Request 58550: AEQ regions being created before the user regions

[Dan Smith]

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



I think the main thrust of this change looks good - get the AEQ created early 
enough to avoid losing data. This seems like the right way to do that! I have 
some comments about cleaning up the code below.


geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
Lines 57 (patched)


Should regionPath really be null for a period of time?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
Lines 58 (patched)


Ready should be volatile if it is used by a separate thread - but in this 
case do we really need a separate ready flag? CountDownLatch.await will just 
return once countDown has been called.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
Lines 71 (patched)


Might need to wait in a loop and check a CancelCriterion or something. It's 
possible the cache gets closed before the latch is counted down, maybe?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
Lines 73 (patched)


Is this really how we want to handle interrupts here? If this thread is 
interrupted, just move on? Seems like you might want to try to wait 
uninterruptibly.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
Lines 63 (patched)


Maybe rename this method, since it also sets the region path on the index?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
Line 59 (original), 69 (patched)


Duplicate code - blow away the old createRepositoryManager if we are not 
using it.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
Lines 114 (patched)


Maybe come up with a better name than "createJustRepoManager?"



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
Line 152 (original), 207 (patched)


This looks like more duplicate code. Remove the old code.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
Lines 249 (patched)


Commented out code.



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
Lines 119 (patched)


Why would the aeq be null here?



geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
Line 170 (original), 171 (patched)


Remove commented out code.


- Dan Smith


On April 20, 2017, 2:03 a.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58550/
> ---
> 
> (Updated April 20, 2017, 2:03 a.m.)
> 
> 
> Review request for geode, Jason Huynh and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Testing a new start up mechanism where the AEQ is created before the user 
> region. Please review and let us know if any modifications are needed, or if 
> this is a viable solution
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  26bb488ed 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneEventListener.java
>  0f5553343 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  fea484547 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImpl.java
>  36f6720c3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneIndexImplFactory.java
>  e99f3d9db 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRawIndex.java
>  75ab5cab3 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneRegionListener.java
>  f4e2a79ef 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/LuceneServiceImpl.java
>  30952bfe2 
>   
> 

Build failed in Jenkins: Geode-nightly #813

[Apache Jenkins Server]

See 


Changes:

[kmiller] GEODE-2103 Update gfsh start server|locator command reference page.

[klund] GEODE-2632: refactor code to use interfaces instead of impls

[kmiller] GEODE-2103 Revise http-service-port defn per review

[boglesby] GEODE-2605: Modified gfsh search lucene to require DATA:WRITE 
privilege

[bschuchardt] GEODE-510 Bug48571DUnitTest.testStatsMatchWithSize failed

[upthewaterspout] GEODE-728: Rename Execution.withArgs to Execution.setArguments

[jstewart] GEODE-2796: ClassPathLoader does not blow up with null TCCL

--
[...truncated 117.13 KB...]
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at sun.nio.fs.UnixPath.toRealPath(UnixPath.java:876)
at 
io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:215)
... 5 more

6853 tests completed, 2 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-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble

[jira] [Created] (GEODE-2803) mark testThinClientPoolExecuteFunction FLAKY

[Ernest Burghardt (JIRA)]

Ernest Burghardt created GEODE-2803:
---

 Summary: mark testThinClientPoolExecuteFunction FLAKY
 Key: GEODE-2803
 URL: https://issues.apache.org/jira/browse/GEODE-2803
 Project: Geode
  Issue Type: Task
  Components: native client
Reporter: Ernest Burghardt


This test needs a refactor to separate its multitude of test cases




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

[jira] [Resolved] (GEODE-2653) GMSJoinLeaveJUnitTest.testRemoveMember fails with AssertionError

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer resolved GEODE-2653.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> GMSJoinLeaveJUnitTest.testRemoveMember fails with AssertionError
> 
>
> Key: GEODE-2653
> URL: https://issues.apache.org/jira/browse/GEODE-2653
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Kirk Lund
>Assignee: Galen O'Sullivan
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Intermittent failure stack:
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest
>  > testRemoveMember FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeaveJUnitTest.testRemoveMember(GMSJoinLeaveJUnitTest.java:337)
> {noformat}
> This test looks like it's flaky due to the Thread sleep:
> {noformat}
>   @Test
>   public void testRemoveMember() throws Exception {
> initMocks();
> prepareAndInstallView(mockMembers[0], createMemberList(mockMembers[0], 
> gmsJoinLeaveMemberId));
> MethodExecuted removeMessageSent = new MethodExecuted();
> 
> when(messenger.send(any(RemoveMemberMessage.class))).thenAnswer(removeMessageSent);
> gmsJoinLeave.remove(mockMembers[0], "removing for test");
> Thread.sleep(ServiceConfig.MEMBER_REQUEST_COLLECTION_INTERVAL * 2);
> assertTrue(removeMessageSent.methodExecuted);
>   }
> {noformat}



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

Re: Review Request 58544: GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl

[Galen O'Sullivan]

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


Ship it!




This is awesome. Using an interface rather than casting everything; deleting 
old comments and commented code; making things more private. I don't know CQs 
or Lucene but it doesn't look like you've changed anything in how they work. 
Excellent!

- Galen O'Sullivan


On April 19, 2017, 11:09 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58544/
> ---
> 
> (Updated April 19, 2017, 11:09 p.m.)
> 
> 
> Review request for geode, Jason Huynh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Dan Smith.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2632 refactoring part 5
> 
> GEODE-2632: refactor code to use InternalCache instead of GemFireCacheImpl
> 
> * minor cleanup: delete dead-code and useless javadocs/comments, reduce scope 
> of vars/methods/constants, misc IDE warnings
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceProvider.java
>  cded9c319e9731f74fb6ec14a7f4a02187ae1603 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/cq/spi/CqServiceFactory.java
>  68ebbd54d4d2459ec8df27b15ace8c83942723f6 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/ClientCQImpl.java
>  00a0aa5a9e7d8f770f2253e2c48dc6319d6864e3 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqQueryImpl.java
>  22b4137c0d52bd84749b9617163b8723d1249ab6 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceFactoryImpl.java
>  db90632437c80879b3ab213bbad34018809f1c31 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceImpl.java
>  f1ca8328ad9b9c67e70292093f117cc885d911b5 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceStatisticsImpl.java
>  ba71143cb271bd177b21e22e00d22a34f69c2834 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/CqServiceVsdStats.java
>  8435c4cea87401a6d29afc65d367d774dc3f4bf6 
>   
> geode-cq/src/main/java/org/apache/geode/cache/query/internal/cq/ServerCQImpl.java
>  ec6e984e24b3dcdf40628bb6f510d0ff96a800f5 
>   
> geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ExecuteCQ.java
>  bcf98063c8ccf7c3d8ba44c9868b8921bb49a64b 
>   
> geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/ExecuteCQ61.java
>  f333b4bdafdadad53060fe11ae9d98cc4f4593d4 
>   
> geode-cq/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/GetDurableCQs.java
>  eac9ed3ad2da2afa92e1230d17b550301631307e 
>   
> geode-cq/src/test/java/org/apache/geode/cache/query/cq/dunit/CqStatsDUnitTest.java
>  7ace0e8e54bedf94622af5f011627a97c6316dd1 
>   
> geode-cq/src/test/java/org/apache/geode/cache/query/cq/dunit/CqStatsUsingPoolDUnitTest.java
>  d6068f1ecc88c076c3d1a8dbd3e3bc944766fbaa 
>   
> geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesFunctionCollector.java
>  66c4c0a298156926793f66eee1ac3efc85b27a14 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/LuceneQueryFunctionJUnitTest.java
>  5313cedd48fa337ef9390a1659ed52dc9d9a0c77 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesCollectorJUnitTest.java
>  3bfebdf2e3b213b6e8b89075f7510f8dc7fbfb4d 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesFunctionCollectorJUnitTest.java
>  bf08877bf4cb1c8be07d69bd0bbdb529a2b2c340 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/internal/distributed/TopEntriesJUnitTest.java
>  fcfebbcb9b46a7beedecc661c31c71836df34dc2 
>   
> geode-lucene/src/test/java/org/apache/geode/cache/lucene/test/LuceneTestUtilities.java
>  556311214371270259c024d565a6b4f0fa6a2146 
> 
> 
> Diff: https://reviews.apache.org/r/58544/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>

Re: Review Request 58518: GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'

[Ken Howe]

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




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


Javadoc comment is no longer needed


- Ken Howe


On April 19, 2017, 11:22 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58518/
> ---
> 
> (Updated April 19, 2017, 11:22 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2795: Clean up DUnit VMs after dynamically changing 'user.dir'
> 
> - LocatorServerStarterRule will now always bounce the DUnit VMs in after() to 
> prevent corrupted cached values of `System.getProperty('user.dir')` that 
> refer to a temporary folder which no longer exists.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  d47b343 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigTestBase.java
>  c5aaa74 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  34506c4 
>   geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberVM.java 
> 05e541a 
> 
> 
> Diff: https://reviews.apache.org/r/58518/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin started (still running)
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-72) Remove deprecated APIs from Geode

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-72:
-

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/456
  
@kirklund , I will create separate PR for each JIRA and then will close 
this PR.


> Remove deprecated APIs from Geode
> -
>
> Key: GEODE-72
> URL: https://issues.apache.org/jira/browse/GEODE-72
> Project: Geode
>  Issue Type: Improvement
>Affects Versions: 1.0.0-incubating
>Reporter: Bruce Schuchardt
>  Labels: cleanup, docs
>
> The Geode APIs are riddled with old, deprecated interfaces, methods and 
> settings inherited from GemFire.  Unless there is a good reason to keep them 
> shouldn't we remove them all before going out of incubation?
> Sub-tasks have been added for most items. Here are the remaining items not 
> yet added:
> APIs deprecated in GemFire 5.1:
> * DLS.lockInterruptibly(), suspendLockingInterruptibly()
>  
> APIs deprecated in an undocumented version prior to 5.7:
> * Use of hostname:port to specify a locator in gemfire.properties
>   
> APIs deprecated after GemFire 5.7 and before 8.0
> * EvictionAlgorithm.LIFO_ENTRY, LIFO_MEMORY: these were deprecated but we 
> never deprecated EvictionAttributes.createLIFOEntryAttributes
> nor EvictionAttributes.createLIFOMemoryAttributes. These algorithms are used 
> internally by the product when a server create a queue to send subscription 
> events to a client (see BridgeServerImpl.clientMessagesRegion). I think the 
> algorithms were deprecated because we didn't intend to expose this internal 
> feature as an external one. But they are exposed externally via 
> EvictionAttributes so it is not clear that we can just delete them.
> The other consideration is that we do not have xsd support nor gfsh support 
> for LIFO.
> * Region.getCache(): we should consider un-deprecating this. Customers were 
> supposed to instead call Region.getRegionService but in lots of cases they 
> would need to down cast that result to "Cache". Only clients that are calling 
> ClientCache.createAuthenticatedView end up with Regions whose getCache throws 
> UnsupportedOperationException. Our code call getCache from over 500 places.
> * Locator.startLocator(int, File), startLocator(int, File, InetAddress) etc.
> * Locator.getLocators(), hasLocators()
> APIs deprecated since GemFire 5.7 with no version information mentioned
> * DistributedRegionMXBean.getDiskTaskWaiting()
> * MemberMXBean.getCurrentHeapSize(), getMaximumHeapSize(), getFreeHeapSize()
> * RegionMXBean.getDiskReadsAverageLatency(), getDiskWritesAverageLatency(), 
> getDiskTaskWaiting()
> Things that should be deprecated but are not:
> * MembershipAttributes and “required roles”.
> * DynamicRegions: if GEODE-215 is implemented then we could deprecate 
> DynamicRegions and have an alternative to change to. We have some support in 
> the gfsh/management layer for creating regions remotely which might be good 
> enough to deprecate DynamicRegions. The question is should we remove 
> com.gemstone.gemfire.cache.DynamicRegionFactory even though it has not been 
> deprecated.
> Deprecated in 7.0 and not previously in this list:
> * UniversalMembershipListenerAdapter
> APIs deprecated in 8.0.  It would probably be a nice gesture to Pivotal to 
> keep these for a while to allow people to migrate from their GemFire product 
> to Geode.
> * PutAllOperationContext.setMap()
> * FixedPartitionResolver.getPartitionName(EntryOperation, Set)
> * ssl-enabled, ssl-protocols, ssl-ciphers, ssl-require-authentication, 
> jmx-manager-ssl distribution properties
> * RegionMXBean.getAvgBucketSize()
> The Admin API and packages are also marked as deprecated but there seem to be 
> some gfsh dependencies on this API, so I'm not sure if it can be removed.
> Also consider removing com.gemstone.gemfire.cache.partition.PartitionListener 
> and com.gemstone.gemfire.cache.partition.PartitionManager.
> They have not been deprecated but were never fully supported. Their javadocs 
> say:
>   Note : Please contact supp...@gemstone.com before using these APIs



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

[GitHub] geode issue #456: GEODE-72 : Remove deprecated APIs from Geode

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/456
  
@kirklund , I will create separate PR for each JIRA and then will close 
this PR.


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